Issuing Certificates via HTTP Validation

The HTTP validation method (http-01) is ideal when you have direct access to the web server hosting your site. Most ACME clients support this method for domain validation and certificate issuance. 

Here’s a high-level overview of the typical workflow when using HTTP validation with an ACME client: 

1. Install and configure your ACME client on the web server. Set it up to communicate with the GlobalSign ACME server using your GlobalSign API key and MAC key. 

2. Submit a certificate request through the ACME client using the HTTP validation method.  
   Note: HTTP is becoming the default validation method for ACME but check your ACME client to determine if you need to specify it directly or not. 

3. Complete domain validation: The ACME client places a unique token in a specific path on your web server. The ACME server then attempts to retrieve this token over HTTP to verify domain control. 

4. Receive and install the certificate: Once validation succeeds, the ACME client retrieves the issued certificate. Depending on your configuration, it may also install the certificate and reload the web server automatically. 

Certbot-specific Instructions

The following steps describe how to issue a certificate using Certbot via the http-01 validation method. 

Prerequisites

1. GlobalSign API & MAC Key from the GlobalSign Atlas portal. These credentials are used to bind Certbot with your Atlas account via Exteranl Account Binding (EAB). 

2. Up-to-date version of Certbot 

3. GlobalSign ACME URL 

Domain Validation and Certificate Issuance

Certbot uses the HTTP validation method by default. 

1. Login to your Linux environment and verify it has the latest version of Certbot by using:  
   
   #certbot --version 

2. If it’s not installed, install Certbot and check the version by using:  
   Sudo yum install certbot 

3. Locate  the document root in your configuration file and copy the root path “/var/www/html”   

4. ​​​​​​Use the following Certbot command to register your account and issue a certificate: 
    
   certbot certonly \ 
     --webroot -w /var/www/html \ 
     --server https://emea.acme.atlas.globalsign.com/directory \ 
     --eab-kid  YOUR_KEY_ID \ 
     --eab-hmac-key YOUR_HMAC_KEY \ 
     -d  example.com 
     -y  --agree-tos 
      --key-type rsa  
    
   Note: Your credentials are linked to either an RSA or ECC certificate product. If your credentials are for ECC certificates, do not include  the key-type flag as Certbot will use the ECC algorithm by default.  

5. If your Atlas account has already been registered to a Certbot client, then you can use the following command to request a certificate using the HTTP validation method: 
   
   certbot certonly \ 
     --webroot -w /var/www/html \ 
     --server https://emea.acme.atlas.globalsign.com/directory \ 
     -d  example.com 
      --key-type rsa  

Once the certificate is issued, you will receive the location of the certificate which will be stored in your files. The private key will be stored there as well; in case you need to configure the certificate for a service. For Apache or NGINX implementations, you can tell Certbot to automatically install the certificate using either the --nginx or --apache flags. 

Renew Certificate 

Certbot typically pre-configures automatic renewal of certificates ordered through the above process. However, if you are unsure if automatic renewal is enabled for your order, please refer to the following documentation for steps on how to verify and implement automatic renewals: https://eff-certbot.readthedocs.io/en/stable/using.html#renewing-certificates 

Note that certificates that are generated manually (using the --manual flag) do not have automatic renewal configured and will need to be manually engaged through authentication hook scripts. Refer to the instructions in the above link for more details.