Hey people. I’m working on figuring out the best way to implement letsencrypt into my web server. I’ve been poking around but still have some general questions:
First, it appears you can put many totally different domain names into one SAN certificate? (as opposed to just doing sub domains of the same parent domain. But I want to confirm this is correct?
Is there a limit to how many different items can be in one SAN certificate?
I’m guessing there is a limit, and that limit is probably pretty high. I currently have about 9 websites hosted on my server, many of those sites have a rich array of subdomains. All have at least “@” and “www”. So there seem to me to be two logical ways to do this, I could put everything in one big certificate, OR I could do one certificate per domain, containing all of the subdomains. Are there reasons I would want to do it one way over another? Doing everything in one cert has the advantage of simpler scripts to manage. But not that much simpler.
Also when I got my first cert, i see that it puts certs into /etc/letcencrypt/live/example.com/…
Where does it get “example.com” from? In other words, say I put example1.com and example2.com into a single cert, what will the path to that cert be? How is that determined?
Lastly for now, does certbot have a command to show all current certificates I have, and some info about them… particularly their expiration date?
Both options would work. I think the two most important considerations are:
If you're hosting, for example, customer domains, it would be problematic if one domain malfunctioning for reasons out of your control -- like if it expired, or the customer misconfigured their DNS -- would stop your certificate from renewing.
Let's Encrypt has rate limits about certificates per domain. If you add or remove (sub)domains and issue new certificates frequently, it might be necessary to isolate those domains to their own certificates.
If you control all your domains and don't issue new ones very frequently, using one big certificate works well.
If you write "-d example1.com -d example2.com" in the Certbot command line, it chooses the first one.
You can use the --cert-name argument to choose a different name (whether it's one of the hostnames in the certificate or completely unrelated) but there isn't a command to rename them after the fact.
The path doesn't really affect anything. It's not saved in the certificate itself or shown to your users. The only person who sees it is you.
Thanks, that’s very helpful. I’ll have more questions soon but this gets me going.
I do fully control my server and all websites I host on it (and domain names).
Also it looks like I easily fit well under all rate limits. “rich array of subdomains” is a very subjective thing.
Another question: When I requested my first cert, it was for “@” and “www” of one domain. It asked me for an email for “important notifications” etc. Was that email a global email for all of my certificates, or just for this specific certificate? How can I change it?
Ok I’m only now starting to understand this fully. The command I use to create the cert, I only have to do once. Then that cert gets added to my account, so all I have to do is the renew command. Because certbot remembers. None of the docs I read actually made it clear how that process worked.
Does cerbot renew a cert every single time you call it, or only if it’s expiring soon?
If I have a cert for some domains, and those domains never change, will I ever have to do any other command besides certbot renew? Or can I expect certbot renew to last me a lifetime (hyperbole).
Also, as a side-question, I don’t suppose theres some hidden option to make certbot certificates output in XML or at least in some other more-machine-friendly format?
It checks twice a day, but only actually tries to renew when an expiration date is within 30 days.
So you could have many certs and it would check them all; but only renew the ones it needs to.
When you say “it checks twice a day”, isn’t it just a command I run with my own script? So I get to decide how often it runs? So what’s the difference if you run it say every hour? It’s not actually going to DO anything unless it needs to. And I don’t imagine it takes much CPU power at all to run?
When you install Certbot (except certbot-auto), it installs a cron job (or systemd timer, depending how modern your OS is) that performs renewal (if necessary) of your certificates every ~12 hours.
It's so every person doesn't need to go setting up their own scripts/timers.
No difference, just overkill. Do it if you want, no real danger.
I thought I read somewhere that the reason they want you to renew twice a day is incase your certificate is revoked for some reason? Wouldn’t it make sense to renew hourly then, so if that happens, it will get cleared up fast without missing any traffic?
They said, I have no idea what kind of problems would cause a certificate to be revoked in the first place so I don’t really know the core of this concept.
That would require checking all certs for revocation - that does require resources on LE side.
[an http call to LE's OCSP server would be required]
After some searching...
It seems certbot does check OCSP everytime it is run.
[it uses certbot.oscp code fort that (which uses OpenSSL)]
Which appears to be a "built-in" function, so there is no exposed parameter to specifically use certbot just for the sole purpose of checking OCSP status.
[there are plenty of online tools/sites for that]
So, then, hourly may actually put undue "stress" on the OCSP system.
[I would stick with the recommended]
Limited access outbound? Are you saying firewall? That’s unlikely because my firewall does not block any outbound connections, only inbound. If that’s not what you mean, then… what do you mean?
The main limited resource for Let's Encrypt is the HSM hardware used to sign certificates and OCSP responses. In both cases, this is proportional to certificate issuance volume, because OCSP responses are signed automatically on a repeating schedule following the issuance of a certificate.
Querying OCSP does use resources, but they're comparatively less limited resources because OCSP responses are handled for Let's Encrypt by the Akamai CDN, which has a lot of capacity. I think avoiding issuing unnecessary duplicative certificates is the most important thing users can do to avoid wasting Let's Encrypt's resources.
Running certbot renew hourly isn't really that harmful in comparison, although I have to say that our rationale for our twice-daily advice is already pretty cautious. It would be extremely unusual to find cases in which your certificate was revoked other than by your own request and yet you're permitted to immediately issue a replacement certificate. I don't think I'm aware of any case in which this has happened in the whole history of the project.
But what is OCSP verification? Why do I need it? Do I need it? Is it a problem that cerbot fails to do it when I renew my certs? Can I safely just ignore that, or is that something I have to look in to?
