A question came up in a discussion with photographers who host on photo sites. The sites (Smugmug, Zenfolio) require a Cname redirect to have a custom domain name. One was told there is a technical issue with installation of certificates since it seems both the DNS and host (Smugmug, who was advising this “customer”) will have to verify security of the site. I searched the community for anything related to Cname redirects but found nothing. How would someone install a certificate in this case? Has this come up?
1 Like
Hi @PamBoling, whoever hosts the site will need to cooperate to obtain and install it. For example, SmugMug could do so if the CNAME is pointing at them (assuming we don’t treat CNAMEs specially, which I doubt).
While other CAs might require other verification methods, Let’s Encrypt’s verification methods will only require the site operator to perform the verification step.
1 Like
@PamBoling, since I replied to your question we have also rolled out DNS verification. This makes it possible for whoever controls the DNS to obtain certificates even without the active involvement of a server or hosting provider. So it would now be possible for people to obtain certificates for their domain without having the hosting provider do anything (of course, the hosting provider has to be willing to deploy the certificates after they’ve been obtained…!).
The DNS verification method is not particularly easy or automated; I’m simply pointing it out as another option that could in principle help people who have HTTPS-capable hosting providers that aren’t set up to actively cooperate with the domain validation process.
1 Like
How would I actually go about obtaining the certificate if I’m using a CNAME? I just ran pulled from the repo and tried generating the certificate, but I get the error that the A record needs to contain the correct IP.
I’ve responded on your other post.
So why are CNAME records not supported with the domain lookup?
Could you be more specific than that? Let’s Encrypt accepts CNAME records, this post was about the fact that merely pointing a CNAME record at a third-party site doesn’t mean that Let’s Encrypt will “just work”, because they’ll have to solve a challenge and provision the certificates. You can even use a DNS-based challenge type that would work without involvement from a third party, except for the part where they have to install the certificate.
If you control both ends of the CNAME record, there shouldn’t be any issue.
(This should probably go in a separate topic, unless it’s actually related for some reason.)
technically CNAMEs should work. I have had enough problems with LE but it does get through my CNAME structure easily enough and I have CNAMEs all over my domains including wildcard CNAMEs and stuff which tand to make matters worse. the only thing you need to remind is that if the CNAME doesnt resolve to an A record at the end of the chain but only to an AAAA (IPv6) record then LE will have the problem that LE doesnt work with IPv6, yet. They do have it on their roadmap though.
Question, if I’m able to generate a cert for a domain , but then later use that domain as a cname (originally it was an A) - would it be portable in the same way as switching servers? Or does the A vs. Cname change everything?
Your existing certificates for that name will continue to work. So if people are still visiting https:///www.example.net/ even though it’s now a CNAME for rnbwd04.example.com instead of an A record with value 172.17.81.91 the certificate for www.example.net continues to be a good certificate to present for this site.
Your new setup will need to pass the periodic re-verification before your certificate expires. If you use DNS verification, the name on the certificate is the one that needs the extra DNS records as before. If you use a web-server based verification method, the fact that it has a CNAME won’t matter, the server that ends up giving responses for the name on the certificate is the one that needs to do verification.
Hope that helps, if not please try to be as clear as possible about your scenario.
The automatic verification fails if a site has no A record.
My domain is named by a CNAME to another name,
Domain “test.X.X.com.au” challenge3 failed. { “type”: “http-01”, “status”: “invalid”, “error”: { “type”: “urn:acme:error:connection”, “detail”: “DNS problem: NXDOMAIN looking up A for test.X.X.com.au”, “status”: 400 }, “uri”: “https://acme-v01.api.letsencrypt.org/acme/challenge/8joNu8TK5ifPQI5LIfZ989WHkoXrRisB-fzDkJFx-i8/314370086”, “token”: “mWitI_vkO6DzHUzvGARyrKp5rIctEXrOtt6soop4QyU”, “keyAuthorization”: “mWitI_vkO6DzHUzvGARyrKp5rIctEXrOtt6soop4QyU.LXLjeu6L0wZQ7BunwIej6lvlUdTDDM2NnbcNjptfdnc”, “validationRecord”: [ { “url”: “http://test.X.X.com.au/.well-known/acme-challenge/mWitI_vkO6DzHUzvGARyrKp5rIctEXrOtt6soop4QyU”, “hostname”: “test.X.X.com.au”, “port”: “80”, “addressesResolved”: null, “addressUsed”: “” } ] }
The domain name in question (found via the challenge URL) has neither a CNAME nor an A record. Note that you need a CNAME or A record for the exact domain you’re requesting a certificate for - not just, for example, for one of the parent domains.
or a aaaa (IP v6) should work too, right?
Yes, that’d work too, but no AAAA record exists either.
We have the same issue, so let me post here instead of a new thread. We have a domain xyz.com which works fine. But sub.xyz.com, which was CNAMEd to an external server now doesn’t work. Could I request for a pointer to the precise steps for “DNS verification” that will help us make this CNAME work too? Thank you.
Update: we set up https for the subdomain using the instructions on ServerFault thread. The issue now is: what to do on the destination server side (Heroku in this case) to ensure the CNAME redirect on that side works? Currently only http works on that side. Thank you!
@PKHunter Heroku supports Let’s Encrypt natively.
There are instructions for enabling it here:
Please note that Heroku only supports SSL with paid plans. If you use a free plan you will be unable to use SSL, even if you purchased a certificate from a commercial CA.