Hey there. I'm well familiar with SSL and have been using lets encrypt for months, but I have an interesting problem that none of the FAQ's seem to cover. I've been running Apache since the SSL support required a commercial product, and my day job involves DNS. This is purely an implementation question, not a help request.
Often, I will set up a site for someone, with a temporary domain name (like username.myhostingco.com) that they can use to test and stage files, and then move their DNS over when they're done. Apache has their domain names (foo.com and www.foo.com) ready to go as ServerAliases. But, until I have some cert to put in place, I can't configure HTTPS support. Lets Encrypt gives me sort of a chicken and egg problem. Apache won't start without a cert configured. (I could certainly point it at a self-signed cert to get it to start up, that's not the question).
Obviously, for certbot to work, DNS needs to be pointed at my server so I can answer the proper challenges. There's no way around this.
What I don't understand is the failure mode if I configure foo.my.com, with foo.com and www.foo.com as aliases. Will I still get a cert, but simply not with the other names attached -- or will the challenge just fail outright.
The client I'm using is Dehydrated. I could certainly switch to something else if this is an advanced feature.
I'm not sure if I properly recognize the quandary, but I'll try to provide some clarity that I believe will unravel things. If I'm explaining something you already know, I apologize.
There are two different types of challenges frequently used for acquiring certificates from Let's Encrypt: http-01 and dns-01.
Satisfaction of an http-01 challenge for x.y.z involves the Let's Encrypt server being able to retrieve a challenge file via a GET request http://x.y.z:80/.well-known/acme-challenge/challengefile. There are many ways of delegating this challenge, such as redirects (even to https with the wrong certificate being served), CNAMEs, and rewrites, to name a few.
Satisfaction of a dns-01 challenge for x.y.z involves the Let's Encrypt server being able to retrieve a TXT record with a host/name of _acme-challenge.x.y.z and a specific value. This challenge can be delegated with a CNAME.
I don't understand exactly what you mean here by alias.
If you are adding a line to your apache vhost config to pass authentication, that would imply HTTP auth is being used. Yet, your theme revolves around DNS authentication.
If HTTP, then all names must resolve to that same IP, for it to pass all HTTP challenges.
If you somehow mean DNS alias (CNAME), then you still need to place all TXT records in their final search destination.
Note: Using CNAME will not reduce the number of DNS TXT requests.
That is, if you have five names and CNAME them all to one name, don't expect just one TXT request - expect all five (to go to the same zone).
I hope some of all this has helped you in some way and you will be able to get the cert you need - with the added name you need.
Once that has been done, you can easily (securely) copy the matching public cert and private key to any other system.
Only one name can be in a certificate's CommonName field. When you have a website that has multiple names to it, these are put in the SubjectAltName field of the certificate. When a [modern] browser compares the certificate to see if it matches, it checks both of these. (Also, the value for CommonName is also often put into SubjectAltName).
I know how to use DNS, I know how CNAMES work. This question is not about that.
Imagine my friend Bob just went to godaddy.com and bought bob.com. He has it parked there right now. I offer to host him for free, and say "upload your content to my server, username 'bob', and you can preview it at bob.nomadhyena.com." That domain will also answer bob.com when Bob points the domain's DNS at my nameservers, but Bob needs to figure that out. (Bob's a noob). If I do HTTP --> HTTPS redirection, I only do it to the same servername the user requested.
But, as soon as Bob asks for a site, I want to be able to hand him a working configuration. https should still work on bob.nomadhyena.com, and there should still be a cert there for it. I do not want to have to wait for the domain to be pointing at me to configure an https vhost.
The question (again, it's in the "Issuance Tech" category) is: If I request a cert with all three of these names, and two of them do not meet their challenges, will I still get a cert, but without those names on it, Or will the Acme protocol basically say "Sorry, all things you're asking for MUST validate, or we issue no cert at all", or (worse) will my IP get blocked for failing too many challenges.
The real question is: Do I need to add logic to my acme-agent to check if the domain is actually pointing at me?
This is an ACME protocol question. Not a "how do I configure my DNS" or "How do I configure apache" question.
No, the question really is: If I've requested a cert with multiple names, is there a "gentle" failure mode such that the names that do not yet validate will be left off the cert but the ones that do, will work?
I fear trying this and hitting some sort of rate-limit.
When performing domain validation, do not consider it a failure if authorizations can not be obtained for a strict subset of the requested domains. This may be useful for allowing renewals for multiple domains to succeed even if some domains no longer point at this system.
There is a Failed Validation limit of 5 failures per account, per hostname, per hour. This limit is higher on our staging environment, so you can use that environment to debug connectivity problems. Exceeding the Failed Validations limit is reported with the error message too many failed authorizations recently.
Technically the common name field has been obsolete for years. Only the subject alternative names actually matter.
So...
The only problem I see is one of canonical name versus address. If Bob wants to see bob.com in the address bar then Bob would need a CNAME record from bob.com to bob.nomadhyena.com, which could then serve a certificate for bob.com (once it's acquired). bob.com would not have an A record at this point. Problem is you can't have a CNAME record for an apex domain name, so Bob would need to change his A record to point to the address of bob.nomadhyena.com. This should pose no problems if you've already setup the vHosts to handle bob.com (and whatever.bob.com). If anyone visits bob.nomadhyena.com before or after the handoff, a correct certificate should be served for bob.nomadhyena.com. SNI takes care of the details.
I would recommend either...
Bob acquire a certificate for bob.com (and whatever.bob.com) before the handoff and securely transfer the certificate and its private key to you.
You acquire a certificate for bob.com (and whatever.bob.com) after the handoff.
Keep in mind that Let's Encrypt ignores invalid SSL certificates for challenge authentication. In essence, serve the wrong certificate and authenticate away! When you "update" that certificate to include bob.com (method 2 above), you'll have a compound certificate that includes bob.nomadhyena.com and bob.com (and whatever.bob.com).
Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep. It only accepts redirects to “http:” or “https:”, and only to ports 80 or 443. It does not accept redirects to IP addresses. When redirected to an HTTPS URL, it does not validate certificates (since this challenge is intended to bootstrap valid certificates, it may encounter self-signed or expired certificates along the way).
Okay, if Certbot supports it, then in theory any other client can as well. (Note that someone earlier in the thread claims it was not supported).
When you say “hostname” I guess that means hostname in the cert. (Not hostname of the requesting machine) So if (for example) my apache config and related certbot-client has expired or transferred-away domains, it's not going to bite me?
Put another way, I'm not looking to get blocked just because someone transfers domains away from me.
Apparently since 2000! This is new info to me. (Maybe someday openssl req -new will stop asking for it, along with info that doesn't commonly get put into certs anymore). Yet, SNI and SubjectAltNames were not a thing that were widely supported for many, many years thereafter by cert vendors.
And no matter what, there's still That Guy who needs CommonName. Oh, if only you knew the hell of your marketing department insisting that someone complained they couldn't load your website in IE6 on Windows XP, Or download your software with an ancient copy of wget.
Of couse. In Apache, I set UseCanonicalName off. Which means Apache will always refer to a given site by whatever address someone reached it by, including in redirects.
Most of my users don't care much about SSL -- it's all personal sites, art sites, and the like. But because browsers have started warning that static sites are insecure, I'm thinking the answer is "certs on every domain".
All in all it's looking like there's going to be three steps in the process:
First, firing in a self-signed cert with the correct SubjectName/CommonName/SubjectAltNames just so apache will start.
Second, firing up my Acme Client once apache is running for Bob, to at least get one cert, even if it can't add hostnames not-yet-pointed at me.
Second-and-a-half: Note the failures and start stalking the DNS for the change.
Lastly, once the domain is properly pointed at me, re-run my Acme Client to refresh the full set.
