Certificate Management

Leveraging the automation provided by ACME, GlobalSign allows ACME clients to request and renew publicly and privately trusted digital certificates from Atlas. Coupled with the Atlas portal, users have visibility of their issued certificates in a GUI platform to centrally manage those certificates and credentials. You can also take advantage of non-ACME domain challenges in the Atlas portal for environments that cannot yet fully adopt ACME workflows. 

Please note that we rotate our TLS ICAs every quarter. Your ACME client will use the provided ICA(s) when configuring your web server. Please refer to this support article for more information. 

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. 

 

Issuing Certificates via DNS Validation 

DNS validation (dns-01) allows you to prove control of a domain by creating a DNS TXT record containing a validation token provided by the GlobalSign ACME server. This validation method is commonly used when HTTP validation is not possible, such as when issuing certificates for wildcard domains or systems that are not publicly accessible over HTTP. 

When using DNS validation, the ACME flow follows these high-level steps: 

1. The ACME client requests a certificate for a domain from the GlobalSign ACME server. 

2. The GlobalSign ACME server returns a unique validation token for the requested domain. 

3. The ACME client creates (or instructs you to create) a DNS TXT record under the _acme-challenge subdomain containing the provided token. 

4. Once the TXT record is accessible via public DNS, the ACME client signals the GlobalSign ACME server to perform validation. 

5. The GlobalSign ACME server queries the domain’s DNS records and verifies the presence of the expected TXT record. 

6. If validation succeeds, the certificate is issued. 

DNS validation must be completed for each domain (or wildcard domain) included in the certificate request. 

For DNS validation to succeed, a publicly resolvable TXT record must exist at _acme-challenge.<domain> containing the validation token provided by the ACME server. TTL values and DNS provider configuration are customer‑specific and do not affect the validation logic itself. 

Using ACME Clients with DNS Validation 

Many ACME clients support DNS validation, either through: 

• Manual DNS updates, where the client outputs the required TXT record and pauses until validation can proceed, or 

• DNS provider integrations, where the client automatically creates and removes DNS records using provider-specific APIs. 

Important Considerations 

• DNS validation requires control over the domain’s DNS configuration. 

• DNS changes may take time to propagate depending on your DNS provider and TTL settings. 

• DNS validation is the required method for issuing wildcard certificates (*.example.com). 

• For automated renewals, DNS validation typically requires either DNS API access or a fully automated DNS plugin. 

 

Issuing Certificates via CNAME Delegation

CNAME records, or Canonical Name records, are a fundamental part of DNS that allow one domain name to serve as an alias for another. They’re commonly used to simplify domain management, support third-party services, and route traffic through content delivery networks (CDNs). Whether you’re pointing www.example.com to a root domain or connecting a custom subdomain to a SaaS platform, CNAMEs offer a flexible and efficient way to manage DNS configurations.  

In ACME implementations, the dns-01 validation method requires placing a specific TXT record under a challenge-specific subdomain. By creating a CNAME record that delegates the ACME challenge to a separate domain you control, you can still complete validation – even if the original domain's DNS is partially or fully managed by a third-party provider. This method gives you flexibility and control over certificate issuance without requiring access to restricted DNS settings. 

Important Notes about CNAMEs 

CNAME records behave a bit differently from other DNS records and come with a few important rules. When a DNS resolver encounters a CNAME while trying to look up another type of record – such as an A or MX record – it follows the alias and restarts the query using the new target name. However, if the resolver is specifically querying for a CNAME record, it simply returns the CNAME itself without restarting the lookup.  

The destination of a CNAME can point to any valid domain, whether it’s within the same DNS zone or on a completely different server. That said, there are a couple key limitations to keep in mind 

• A domain with a CNAME record cannot have any other record types (such as A, MX, or TXT). 

• CNAMEs cannot be used at the root of a domain (also known as the zone apex), since that level requires records like NS, which must exist independently. 

Create CNAME Record 

Start by manually creating a CNAME record for the domain you want to secure with a certificate. This record delegates the dns-01 challenge to another domain where the actual TXT record will be hosted. The name of the CNAME record must begin with the “_acme-challenge" prefix.  

The target domain in the CNAME record (where the TXT record will be hosted) may begin with an underscore, but it’s not required. 

For example, if you’re issuing a certificate for example.com but want to host the TXT record at example.net, you would create one of the following CNAME records: 

_acme-challenge.example.com      CNAME      _acme-challenge.example.net 
_acme-challenge.example.com      CNAME      example.net 

This tells the ACME client and resolvers that the TXT validation token for example.com can be found at example.net. 

Request the Certificate Using ACME 

Use your ACME client to request a certificate for the original domain (example.com). During the dns-01 validation process, the ACME client will detect the CNAME at _acme-challenge.example.com and follow it to the target domain (e.g. _acme-challenge.example.net). It will then place the required TXT record at that target domain, allowing the challenge to be satisfied without needing to create or update TXT records directly in the DNS zone of the original domain. 

Complete the Validation 

Once the TXT record is in place at the target domain (example.net), the ACME client will notify the GlobalSign ACME server to complete the domain validation. The GlobalSign ACME server will query the original _acme-challenge.example.com record, follow the CNAME to the target, check for the correct TXT value, and issue the certificate for example.com. 

Technical Reminders 

• The prefix must be “_acme-challenge" You cannot use any other prefix for CNAMES with the GlobalSign ACME service. 

• The TXT record that is generated during the domain challenge process is case sensitive. In most cases this shouldn’t cause any issues, but if you have a process that moves the TXT record outside of the automated ACME workflow, be sure to preserve the case of the TXT record, otherwise you will receive an error during the certificate request process. 

 

Renew a Certificate 

ACME clients are designed to automatically renew certificates before they expire. As the expiration date approaches, the client submits a new certificate request to the ACME server and follows the same domain validation (if required) and issuance process used for the original certificate. 

If a certificate was issued manually, automatic renewal may not be configured by default. In these cases, refer to the documentation for your ACME client to determine how renewals should be set up. 

 

Revoke a Certificate 

Certificate revocation invalidates a certificate before its scheduled expiration date. Revocation is typically used in cases of private key compromise, accidental exposure, or other security incidents. 

Most ACME clients support certificate revocation, though the method and available options vary by client. When revoking a certificate, the ACME server updates the certificate’s status so that relying parties can detect that it should no longer be trusted. 

Because ACME certificates are short‑lived, revocation is not always required when replacing a certificate. Refer to your ACME client’s documentation for client‑specific revocation commands and options.