Troubleshooting Let’s Encrypt issues

When requesting a Let’s Encrypt Certificate on MODX Cloud, you may come across errors that prevent you from getting a certificate. In other cases, you may find that your Let's Encrypt Certificate did not automatically renew as it should (every sixty days).

This article outlines a few troubleshooting procedures to help resolve the issue or if it’s something the MODX Cloud Support team needs to review.

Are All the Assigned Domains Pointing to Cloud?

Check Assignment

The first thing to do is ensure all the domains point to the Cloud in question and they are assigned to the cloud.

To check to make sure the Domains are assigned, locate the Cloud Edit view by findind the Cloud in your list of Clouds and click on the name. Then go to the Domains tab. Make sure you see the all the domains that should be pointed to the Cloud in the list of domains.

Check DNS

The second thing to do is verify the domains have an A record, but no AAAA (IPv6) record. Unfortunately MODX Cloud doesn't yet support IPv6 and this will cause the Let's Encrypt issuance to fail.

If you're not familiar with command line tools you can use the GSuite Toolbox to check your domains one at a time. Be sure to check to make sure there is a valid A Record and the IP address matches the IP address of your Cloud. Then make sure there is no AAAA Record. If there is, you'll need to go to your DNS provider/registrar to remove the AAAA record.

Repeat this with each of your domains.

If you do have experience using a the command line you can use the following procedure:

  1. In a Mac/Linux terminal create a text file with the domains to check; one domain per line and name it domaincheck.txt
  2. Run the following command inside the same directory as the file you created to check for A recorces.:
    for i in `cat domaincheck.txt`; do dig $i type257; done
  3. Then the following command inside the same directory as the file you created check for AAAA records:
    for i in `cat domaincheck.txt`; do dig $i AAAA; done

 

Example Type257 output:

dig domain.com type257
; <<>> DiG 9.10.3-P4-Ubuntu <<>> domain.com type257
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- oppre: QUERY, status: NOERROR, id: 52131
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;domain.com. IN CAA ;; ANSWER SECTION:
domain.com. 10800 IN CAA 0 issue "randomca.com" ;; Query time: 81 msec
;; SERVER: 67.207.67.2#53(67.207.67.2)
;; WHEN: Thu Mar 22 13:39:12 UTC 2018
;; MSG SIZE rcvd: 78

Here you're looking for an error:

;; ->>HEADER<<- oppre: QUERY, status: NOERROR, id: 52131

and for the output here:

;; ANSWER SECTION:
domain.com. 10800 IN CAA 0 issue "randomca.com"

If you see NOERROR and don't see anything after CAA, the issue is not here.

Example AAAA output:

dig domain.com AAAA
; <<>> DiG 9.10.3-P4-Ubuntu <<>> domain.com AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- oppre: QUERY, status: NOERROR, id: 50786
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN AAAA ;; ANSWER SECTION:
domain.com. 87 IN AAAA 2607:f8b0:4006:813::200e ;; Query time: 3 msec
;; SERVER: 67.207.67.2#53(67.207.67.2)
;; WHEN: Thu Mar 22 15:48:33 UTC 2018
;; MSG SIZE rcvd: 67

Here you're looking for an IPv6 address:

;; ANSWER SECTION:
domain.com. 87 IN AAAA 2607:f8b0:4006:813::200e

If the IPv6 address is there, remove it from your DNS entries.

Check for Blocking Web Rules

There are some errors in web rules that can prevent the Let's Encrypt validation to complete. Any rule that redirects domains but does not include the $request_uri part of the rule will be redirecting all redirects to the front page of the site rather than the full URL and any traffic trying to reach a subdirectory will be redirectd to the root domain.

Example error causing web rule:

if ($host = "www.mydomain.com") {
return 301 $scheme://mydomain.com;
}

The above will route all requests for www.mydomain.com to the main domain's index.

The correct rule should include the $request_uri variable as follows:

if ($host = "www.mydomain.com") {
return 301 $scheme://mydomain.com$request_uri;
}

This will work correctly and allow the domains to be validated if everything else is working.

Still not Working? Contact Support

If everything looks good in those three steps, open a support ticket using the green help button in the MODX Cloud Dashboard or email support@modxcloud.com with the Internal URL of the Cloud having Let’s Encrypt errors.

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.