Some suggestions to make it clearer that when using Let's Encrypt, the public DNS entries for the site and all domain aliases need to be A RECORDS (Not CNAMEs).
A) in Documentation
(Re documentation at https://matteobrusa.github.io/md-styler/?url=cgit.drupalcode.org/hosting...)
Under Site Set Up
Change from
Site Set Up
1. Ensure that there's a DNS entry for the site that you'd like HTTPS enabled (unless already handled by a wildcard entry pointing to your Aegir server).
to
Site Set Up
1. Ensure that there is a public DNS entry for the site that you'd like HTTPS enabled for and for each of its domain aliases (unless already handled by a wildcard entry pointing to your Aegir server). Attention: if you use Let's Encrypt certificates, the public DNS entries for your site and for all its domain aliases need to be A RECORDS (Not CNAMEs).
Under Troubleshooting
Add a section
Check DNS entries
If you use Let's Encrypt, check that the public DNS entries for your site and all of its domain aliases are A RECORDS.
$ dig +noall +answer my.domain.com
B) in AEGIR user interface
In Site Edit form, section HTTPS Settings
Change the warning from
If the server is setup to generate the HTTPS certificate using Let's Encrypt, ensure that there is an existing public DNS entry for the site, otherwise installation will fail.
to
Attention: If the server is setup to generate the HTTPS certificate using Let's Encrypt, ensure that there is an existing public DNS entry for the site and for each of its domain aliases, and that all these DNS entries are A RECORDS (NOT CNAMEs), otherwise installation will fail.
Comment | File | Size | Author |
---|---|---|---|
#5 | ClarifyNeedForDnsArecords-2950359-4.patch | 1.94 KB | agaq |
Comments
Comment #2
colanThat documentation page is simply rendering the markdown in the README.md file. Patches welcome. :)
Comment #3
agaq CreditAttribution: agaq as a volunteer commentedHappy to try but not sure how to do that?
From https://www.drupal.org/project/hosting_https, I followed the link to Resources > Home Page which leads to GitLab but the project page there (at https://gitlab.com/aegir/hosting_https) shows an older version of the README.md file.
I also found my way to http://cgit.drupalcode.org/hosting_https/
Happy to try if I can be pointed in the right direction :-) Where do I do that and where can I find help/documentation?
Comment #4
colanThis project was formerly hosted on Gitlab, but it's now here. Sorry about the confusion.
That cgit URL is this project's code. On the main project page here for Aegir HTTPS, click on the Version Control tab. It will tell you how to interact with the code. See Making a Drupal patch with Git for info on creating patches, which you would then upload here, this issue.
To edit the README.md , you could edit it with a text editor, but there are editors available that will show you rendered text, which is much more useful. I like Retext (as it's available in the Ubuntu repositories), but I'm not sure what platform you're on.
Comment #5
agaq CreditAttribution: agaq as a volunteer commentedHere is a patch for the documentation (if I did it all correctly...)
Comment #6
colanPatch looks good, but I was trying to find a reference for this. It looks like CNAMEs are actually supported, but poor error reporting led to this belief. See Why does ACME / Let's Encrypt require A records not CNAME? for details. Can you confirm?
From a comment in Failed authorization procedure for CNAME domains: Former working setup stopped working:
If you're correct though, please provide a reference in the patch, set the status back to Needs Review, and then we can continue with this. Thanks for working on it!
Comment #7
agaq CreditAttribution: agaq as a volunteer commentedThe only thing I did to solve the problem was change the DNS entry for the domain alias from a CNAME to an A record.
Will replicate and check.
PS thanks for the instructions. Used Retext (am on Ubuntu).
Comment #8
agaq CreditAttribution: agaq as a volunteer commentedHmmm. I am NOT able to replicate the problem...
Will continue testing and report back in more details.
Comment #9
agaq CreditAttribution: agaq as a volunteer commentedI have not been able to replicate the problem reliably.
What I am certain happened, in sequence:
- I had a hostmaster site master.domain.com with a domain alias secondary.domain.com (which was a CNAME to master.domain.com)
- trying to activate HTTPS with let's encrypt (HTTPS either required or enabled) failed consistently with the task log showing:
Failed to generate Let's Encrypt certificates. - warning
- when I realised I could re-run a task manually to get much more verbose output (using "
drush hosting-task --debug --force $task-number
"), I re-run the last task that failed and I got:- I removed the domain alias secondary.domain.com from the site configuration
- I re-tried to activate HTTPS and it worked fine, immediately, generating a LE certificate successfully
- I changed the DNS entry for secondary.domain.com from a CNAME to an A record and waited about 12h
- I re-added secondary.domain.com as a domain alias to the site configuration and the verify task worked fine, updating the certificate to include secondary.domain.com as a Subject Alternative Name (SAN).
I did a number of subsequent tests with a range of master domains (a records and cnames) and domain aliases (a records and cnames). All combinations worked fine.
The occasional problems I had were with transitions between "HTTPS required" and "HTTPS enabled" and only happened when I was using STAGING rather than PRODUCTION. Sometimes the initial verify task would fail but the manual re-run of the task shortly afterwards would succeed. When the re-run failed as well, I would get:
ERROR: An error occurred while sending get-request to http://cert.stg-int-x1.letsencrypt.org/ (Status 301)
I would propose to wait until the full Let's Encrypt output shows up in the task log before I run further tests.
Comment #10
colanLet's wait for #2952411: Restore Let's Encrypt log output in Verify tasks then.
Comment #13
colanClosing as there doesn't seem to be any evidence that this can be reproduced.