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.

CommentFileSizeAuthor
#5 ClarifyNeedForDnsArecords-2950359-4.patch1.94 KBagaq
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

antoine.guichard created an issue. See original summary.

colan’s picture

That documentation page is simply rendering the markdown in the README.md file. Patches welcome. :)

agaq’s picture

Happy 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?

colan’s picture

Version: 7.x-3.140 » 7.x-3.x-dev
Category: Feature request » Task

This 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.

agaq’s picture

Status: Active » Needs review
FileSize
1.94 KB

Here is a patch for the documentation (if I did it all correctly...)

colan’s picture

Status: Needs review » Postponed (maintainer needs more info)

Patch 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:

CNAMEs are fine. The error message shows an IP address (which I assume was the correct one at the time), so it’s not related to DNS. Let’s Encrypt simply was unable to connect to port 443 during verification. This could be for any number of reasons - maybe your ISP is blocking incoming connections on port 443 (possibly not all connections, but based on some heuristic - this is not uncommon for residential ISPs). It’s rather hard to make a more educated guess here, since the only thing this error is telling us is that the validation server didn’t reach yours.

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!

agaq’s picture

The 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).

agaq’s picture

Hmmm. I am NOT able to replicate the problem...

Will continue testing and report back in more details.

agaq’s picture

I 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:

ERROR: Challenge is invalid! (returned: invalid) (result: {
    "type": "http-01",
    "status": "invalid",
    "error": {
      "type": "urn:acme:error:connection",
      "detail": "DNS problem: NXDOMAIN looking up A for drupal.latitude.aq",
      "status": 400
    },

- 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.

colan’s picture

Status: Postponed (maintainer needs more info) » Postponed

  • helmo committed e15cbc7 on 7.x-3.x
    Issue #2950359 by antoine.guichard: Make it clearer that LetsEncrypt...

colan credited helmo.

colan’s picture

Status: Postponed » Closed (works as designed)

Closing as there doesn't seem to be any evidence that this can be reproduced.