Questions[ssl-certificate-renewal](server)

The certbot command provides two hooks that run after automated renewals, from the docs:

 --post-hook POST_HOOK
                       Command to be run in a shell after attempting to
                       obtain/renew certificates. Can be used to deploy
                       renewed certificates, or to restart any servers that
                       were stopped by --pre-hook. This is only run if an
                       attempt was made to obtain/renew a certificate. If
                       multiple renewed certificates have identical post-
                       hooks, only one will be run. (default: None)
 --deploy-hook DEPLOY_HOOK
                       Command to be run in a shell once for each
                       successfully issued certificate. For this command, the
                       shell variable $RENEWED_LINEAGE will point to the
                       config live subdirectory (for example,
                       "/etc/letsencrypt/live/example.com") containing the
                       new certificates and keys; the shell variable
                       $RENEWED_DOMAINS will contain a space-delimited list
                       of renewed certificate domains (for example,
                       "example.com www.example.com" (default: None)

This issue is outlined in this (now closed) LE thread and is basically about minimising interruption to services. POST_HOOK executes every time an attempt to renew is made even if no certificates were issued, though only once. This makes it possible to unnecessarily restart services. DEPLOY_HOOK runs for each and every successful certificate renewal. If one uses DEPLOY_HOOK, and has multiple certificates, each service may restart multiple times when once is enough. More info on renewal hooks here.

I use an issuance method that does not interrupt my services at all, e.g.:

certbot certonly --webroot ...

or

certbot certonly --dns-PROVIDER ...

I want to restart/reload each dependent service only once, and only if its certificate actually changed.

I understand the initial challenge-response pattern when using Let's Encrypt, but I noticed that when testing renewals, no GET requests were hitting .well-known/acme-challenge.

Once the domain/account keys are setup, does renewal ever have to touch .well-known? Can my account/domain keys ever expire and have to be refreshed?

My app requires specific mounts to serve that directory and if possible I would like to avoid the configuration overhead if it won't ever be used anyway. I can use a slimmer setup for the initial domain verification.

I manage an apache web server for a government site. The SSL cert will expired in a few weeks so they sent me a zip file with 3 intermediate certs and the ssl certificate (I have the private key from the csr generator and the crt file provided by gov't). I need to bundle the intermediate certs into one file for apache2.

Here are the 3 intermediate certs they sent me

Jan  1  2004 AAACertificateServices.crt
Nov  2  2018 SectigoRSADomainValidationSecureServerCA.crt
Mar 12  2019 USERTrustRSAAAACA.crt

In what order should I bundled the 3 certs because from reading from other links, the order does matter if the root is provided. Which one is the root?

I used an online ssl validator for the the 3 certs

AAACertificateServices.crt

Common Name: AAA Certificate Services
Organization: Comodo CA Limited
Locality: Salford
State: Greater Manchester
Country: GB
Valid From: December 31, 2003
Valid To: December 31, 2028
Issuer: AAA Certificate Services, Comodo CA Limited
Serial Number: 1 (0x1)

SectigoRSADomainValidationSecureServerCA.crt

Common Name: Sectigo RSA Domain Validation Secure Server CA
Organization: Sectigo Limited
Locality: Salford
State: Greater Manchester
Country: GB
Valid From: November 1, 2018
Valid To: December 31, 2030
Issuer: USERTrust RSA Certification Authority, The USERTRUST Network Write review of Sectigo
Serial Number: 7d5b5126b476ba11db74160bbc530da7

USERTrustRSAAAACA.crt

Common Name: USERTrust RSA Certification Authority
Organization: The USERTRUST Network
Locality: Jersey City
State: New Jersey
Country: US
Valid From: March 11, 2019
Valid To: December 31, 2028
Issuer: AAA Certificate Services, Comodo CA Limited Write review of Sectigo
Serial Number: 3972443af922b751d7d36c10dd313595

This has been a gray area for me since I've been using LetEncrypt and they automatically bundle the intermediate certs on to one file.

I have a server file like this

server {
listen 80;
server_name subdomain.example.com;

return 301 https://$server_name$request_uri;

location /.well-known/acme-challenge {
        root /var/www/letsencrypt;
    }
}

Now when I try sudo letsencrypt renew. It throws up and error saying can't find .well-known/acme-challenge. But as soon as I commented the return 301 line restarted the server and It worked.

Now I want to retest it putting the location first and not commenting the return 301 statement but it says certificate not due for renewal.So the question is does order in which the file is read, does it matter? and it won't automatically renew because of this reason for me, those who do renewal how do you handle this situation?

I'm using ssl-cert-check to track a list of my domains certificates.

In my crontab I set it to run quietly and email me expiring domains, but the command that I'm using to debug is:

ssl-cert-check -f ssldomains.txt -x 21 -i

It is correctly reading the file and retrieving the certificates for the entire list, but it does not appear to be getting the correct expiry date for certificates issued by LetsEncrypt.org

Other certificate providers do not seem to be affected by this problem.

For example a certificate that is expiring on 24 March 2017 when I inspect it in my browser is reported to be expiring on 15 Jan 2017.

I'm serving with nginx.

Why would the CLI tool be retrieving the wrong expiry date and how can I correct this?