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?
It’s a global email for that ACME account. A Certbot installation typically uses one account for all certificates.
sudo certbot update_account -m firstname.lastname@example.org
sudo certbot register --update-registration -m email@example.com
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.
I have never heard of any (sorry).
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…
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]
Well that’s interesting because when I do either:
After it lists certificates, give me pathes, dates, tells me it’s not old enough to be renewed etc, I also get the following note:
OCSP check failed for /etc/letsencrypt/live/fellsbiker.com/cert.pem (are we offline?)
What do you suppose that is all about? It seems to still be functioning just fine.
It gets the OCSP settings (URL) from the cert and then uses it to verify the status.
So, it would seem that your system has limited access outbound.
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.
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.
I just read that whole post but I don’t understand it unfortunately.
It tries to shows how to verify OCSP manually.
[which is pretty much what
cerbot would do every time it is called]
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?
It is built into the cert and certbot tries to verify it at every run.
I can be ignored, it will just delay the certbot run.
But I would still look into why your system can’t get the ocsp file (a simple http get).
curl -I http://ocsp.int-x3.letsencrypt.org/
HTTP/1.1 200 OK
Expires: Sat, 16 Feb 2019 10:42:43 GMT
Date: Sat, 16 Feb 2019 06:35:31 GMT
That looks right.
certbot certificates -vvv
Then show the log file.
certbot certificates -vvv
2019-02-16 01:39:53,457:DEBUG:certbot.main:certbot version: 0.30.2
2019-02-16 01:39:53,458:DEBUG:certbot.main:Arguments: [’-vvv’]
2019-02-16 01:39:53,458:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2019-02-16 01:39:53,507:DEBUG:certbot.log:Root logging level set at -10
2019-02-16 01:39:53,508:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2019-02-16 01:39:53,525:DEBUG:certbot.ocsp:Querying OCSP for /etc/letsencrypt/live/fellsbiker.com/cert.pem
2019-02-16 01:39:53,526:DEBUG:certbot.ocsp:openssl ocsp -no_nonce -issuer /etc/letsencrypt/live/fellsbiker.com/chain.pem -cert /etc/letsencrypt/live/fellsbiker.com/cert.pem -url http://ocsp.int-x3.letsencrypt.org -CAfile /etc/letsencrypt/live/fellsbiker.com/chain.pem -verify_other /etc/letsencrypt/live/fellsbiker.com/chain.pem -trust_other -header Host ocsp.int-x3.letsencrypt.org
2019-02-16 01:39:53,531:DEBUG:certbot.ocsp:Error while running openssl ocsp -no_nonce -issuer /etc/letsencrypt/live/fellsbiker.com/chain.pem -cert /etc/letsencrypt/live/fellsbiker.com/cert.pem -url http://ocsp.int-x3.letsencrypt.org -CAfile /etc/letsencrypt/live/fellsbiker.com/chain.pem -verify_other /etc/letsencrypt/live/fellsbiker.com/chain.pem -trust_other -header Host ocsp.int-x3.letsencrypt.org.
[OSCP usage options - redacted for brevity]
2019-02-16 01:39:53,531:INFO:certbot.ocsp:OCSP check failed for /etc/letsencrypt/live/fellsbiker.com/cert.pem (are we offline?)