Discrepancy between expiration email and certbot


#1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: theprequel.org

I ran this command: certbot renew

It produced this output:


Processing /etc/letsencrypt/renewal/theprequel.org.conf


Cert is due for renewal, auto-renewing…

Plugins selected: Authenticator nginx, Installer nginx

Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org

Renewing an existing certificate

Performing the following challenges:

tls-sni-01 challenge for www.theprequel.org

tls-sni-01 challenge for theprequel.org

Cleaning up challenges

Attempting to renew cert (theprequel.org) from /etc/letsencrypt/renewal/theprequel.org.conf produced an unexpected error: Could not automatically find a matching server block for www.theprequel.org. Set the server_name directive to use the Nginx installer… Skipping.


Processing /etc/letsencrypt/renewal/theprequel.org-0001.conf


Cert not yet due for renewal

All renewal attempts failed. The following certs could not be renewed:

/etc/letsencrypt/live/theprequel.org/fullchain.pem (failure)


The following certs are not due for renewal yet:

/etc/letsencrypt/live/theprequel.org-0001/fullchain.pem expires on 2018-11-30 (skipped)

All renewal attempts failed. The following certs could not be renewed:

/etc/letsencrypt/live/theprequel.org/fullchain.pem (failure)


1 renew failure(s), 0 parse failure(s)

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is: linode

I can login to a root shell on my machine (yes or no, or I don’t know):yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):


#2

Hi,

What are you trying to archive?
If you want to renew your certificates, you’ll need to resolve the error in your nginx virtual host first…

Thank you


#3

Hi @lewisl

there is a “mixed situation”: You have two certificates:

https://transparencyreport.google.com/https/certificates?cert_search_auth=&cert_search_cert=&cert_search=include_expired:false;include_subdomains:false;domain:theprequel.org&lu=cert_search

One from 23.06.2018 - 21.09.2018 with theprequel.org + www.theprequel.org, two with only theprequel.org as name, the last is installed.

But Certbot cannot understand your nginx - configuration:

And: The tls-sni-01 - validation is deprecated.

If you need one certificate with two names, try something like

certbot --nginx --preferred-challenges http-01 -d theprequel.org -d www.theprequel.org

If this works and if the new certificate is installed, you can delete your older certificates.


#4

I think my directories and symlinks are messed up. It is hard when things get duplicated by scripts and you need to clean up after. Sometimes you kill a symlink and create a file where a symlink is expected.

run: certbot certificates

Output:

certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewal configuration file /etc/letsencrypt/renewal/theprequel.org-0001.conf produced an unexpected error: expected /etc/letsencrypt/live/theprequel.org-0001/cert.pem to be a symlink. Skipping.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: theprequel.org
    Domains: theprequel.org
    Expiry Date: 2018-11-30 15:51:38+00:00 (VALID: 79 days)
    Certificate Path: /etc/letsencrypt/live/theprequel.org/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/theprequel.org/privkey.pem

The following renewal configuration files were invalid:
  /etc/letsencrypt/renewal/theprequel.org-0001.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

So, what lead to this was I did a fully manual install of ghost OR ghost-cli (which is hooey but you can’t tell them that or you hurt their feelings) put certificates in the wrong place. Then, I used certbot to renew and it put them in the right place but named everything as the prequel.org-0001. I wanted to get rid of the old prequel.org files so renamed them all prequel.org-old and renamed prequel.org-0001 as prequel.org. Now, the renewal configuration files are all wrong because they refer to the prequel.org-0001.

There is more strangeness in the directories and symlinks (described below), but ghost and nginx work because they can find certs in a place that the server blocks reference.

So, I have tried to rename things to make the newly setup certs (with expiration Nov. 30, 2018) called just theprequel.org and the former ones (with expiration Sept. 20, 2018) called theprequel.org-old. Ultimately, when this is all setup properly, I can either delete all directories, symlinks, and files using the theprequel.org-old nomenclature–or ignore them because they are not being used at all. Naturally, it’s better to get rid of detritus.

So, I resolved the problem that you see above. I no longer get a message about renewal config. When I run certbot certificates, the output is:

root@lewlin1:/etc/letsencrypt/renewal# certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: theprequel.org
    Domains: theprequel.org
    Expiry Date: 2018-11-30 15:51:38+00:00 (VALID: 79 days)
    Certificate Path: /etc/letsencrypt/live/theprequel.org/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/theprequel.org/privkey.pem
  Certificate Name: theprequel.org-old
    Domains: theprequel.org
    Expiry Date: 2018-11-30 15:51:38+00:00 (VALID: 79 days)
    Certificate Path: /etc/letsencrypt/live/theprequel.org/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/theprequel.org/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

But, as you can see certificates with two different names actually point to the same files. That’s where the directories and symlinks seem messed up.

So, here is the current dir structure with symlinks at the file level rather than at the directory level:

/etc/letsencrypt/renewal
        theprequel.org.conf       # a file
        theprequel.org-old.conf # a file

the preceding seems ok. Later, I cat the file so you can we which certificates are setup for renewal.

/etc/letsencrypt/live
      theprequel.org
             cert.pem -> ../../archive/theprequel.org-0001/cert1.pem
             chain.pem -> ../../archive/theprequel.org-0001/chain1.pem
             fullchain.pem -> ../../archive/theprequel.org-0001/fullchain1.pem
             privkey.pem -> ../../archive/theprequel.org-0001/privkey1.pem
             README
      theprequel.org-old
             cert.pem -> ../../archive/theprequel.org/cert1.pem
             chain.pem -> ../../archive/theprequel.org/chain1.pem
             fullchain.pem -> ../../archive/theprequel.org/fullchain1.pem
             privkey.pem -> ../../archive/theprequel.org/privkey1.pem
             README

So, live directory is wrong because I think these are supposed to be symlinks to the archive directory rather than physical directories. Instead, each file in the live directory is symlinked to a file in the archive directory. And both domain name directories contain symlinks to the same files, as certbot certicates reports above.

Here is what the archive directory looks like:

/etc/letsencrypt/archive
     theprequel.org
           cert1.pem  
           chain1.pem  
           fullchain1.pem  
           privkey1.pem
     theprequel.org-0001
           cert1.pem  
           chain1.pem  
           fullchain1.pem  
           privkey1.pem

OK, so I didn’t compare all of the files but cert1.pem is the same in both directories, so I think its pretty likely that all the files match. So, it only looks like I have 2 certs. Really, I have the same certs for 2 different domains.

What I am thinking I should do to straighten this out is as follows:

  1. In directory live, make theprequel.org a symlink to the directory of the same name in archive.
  2. In directory live, get rid of the directory theprequel.org-old
  3. even though I thought that theprequel.org-0001 were newer they are the same, but to be on the safe side, in the directory archive rename thepreq.org to the prequel.org-old.
  4. the in the directory archive I can rename the directory prequel.org-0001 to just theprequel.org

For completeness, this is what the server block in nginx looks like for the domain theprequel.org. This is a symlink from sites-enabled to sites-available and from there symlinked to ghost. That is how ghost does it even though that is not such a hot idea (but the owner is NOT the user that the ghost web server code uses while it is running and serving content). It looks like this:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name theprequel.org;
    root /var/www/prequel/ghost/system/nginx-root;
    ssl_certificate /etc/letsencrypt/live/theprequel.org/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/theprequel.org/privkey.pem; # managed by Certbot
    include /etc/nginx/snippets/ssl-params.conf;
    
    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:2368;
        
    }
    
    location ~ /.well-known {
        allow all;
    }
    
    client_max_body_size 50m;

}

That looks fine and it won’t see any difference after I clean up the directories.

Do you think my cleanups are the right thing to do?

By the way nginx -t reports that it is happy with the config. Ghost is also happy.


#5

Modifying the structure of /etc/letsencrypt without understanding it is likely to break referential integrity between the items there (which is what you’ve experienced here).

Nope, the files in the live directory are required to be individual symlinks to specific files in the archive directory.

Instead of

/etc/letsencrypt/live
      theprequel.org
             cert.pem -> ../../archive/theprequel.org-0001/cert1.pem
             chain.pem -> ../../archive/theprequel.org-0001/chain1.pem
             fullchain.pem -> ../../archive/theprequel.org-0001/fullchain1.pem
             privkey.pem -> ../../archive/theprequel.org-0001/privkey1.pem
             README

you should have

/etc/letsencrypt/live
      theprequel.org
             cert.pem -> ../../archive/theprequel.org/cert1.pem
             chain.pem -> ../../archive/theprequel.org/chain1.pem
             fullchain.pem -> ../../archive/theprequel.org/fullchain1.pem
             privkey.pem -> ../../archive/theprequel.org/privkey1.pem
             README

Certbot makes some assumptions about these relationships and can break when the assumptions are violated. That’s why that README file says

WARNING: DO NOT MOVE THESE FILES!
Certbot expects these files to remain in this location in order
to function properly!
We recommend not moving these files. For more information, see the Certbot
User Guide at https://certbot.eff.org/docs/using.html#where-are-my-certificates.

Instead of

you should make the individual files in live be relative symlinks to the corresponding files in archive, as I’ve described above. The corresponding configuration file in renewal should also then refer to the individual files in live.

I’m sorry that Certbot so readily creates duplicate certificate lineages. It happens automatically whenever you request a certificate that covers names that aren’t a superset of the names in an existing certificate.

In your case, it probably happened because you had this certificate

https://crt.sh/?id=552917575

covering both www.theprequel.org and theprequel.org, but then you subsequently requested this certificate

https://crt.sh/?id=703208580

covering only theprequel.org. Certbot concluded that (1) this couldn’t be a replacement for the old certificate, because it didn’t include www.theprequel.org, (2) this couldn’t be a request to renew the old certificate, because it didn’t mention www.theprequel.org, (3) you were nevertheless requesting a certificate, so a separate certificate should be requested and managed by Certbot as theprequel.org-0001.

Certbot never assumes that any names that weren’t explicitly mentioned on the command should be included in a certificate request, but also never assumes that you want to reduce the coverage of an existing certificate (unless you specify --cert-name). So if you have a partially overlapping list of names that omits any names in the pre-existing certificate, you always get a duplicative overlapping certificate instead.

It seems like this default may have been a mistake and perhaps we should have made --cert-name mandatory whenever domain names overlap in this way (in order to force the user to explicitly decide whether to reduce the coverage of the existing certificate or to create a duplicative certificate). Unfortunately, we hadn’t created the --cert-name option at all when we first established the duplicate-cert behavior.


#6

Thanks for your answer and the additional insight.

Since I need to keep the symlinks to individual files, I am already quite close.

Thanks for pointing out the importance of the first character group before the period. I was sort of thinking that only the middle and the TLD mattered and the beginning part didn’t.

How about subdomains as in theprequel.org/foo? Seems like that could all be one certificate and nginx would handle the routing on the server the appropriate directory.

Glad I asked before I did any more hacking. FAST reply!


#7

That’s not a subdomain in the DNS (or certificate) sense, though. That can indeed be one certificate (and a certificate only covering one domain name) because the certificate only needs to refer to the hostname (like theprequel.org), and the nginx can serve requests for any path or query after the slash. However, covering www.theprequel.org in the certificate can be a good idea because some user might type that.


#8

Can I get a certificate to cover
www.domain.org
and domain.org? How about if I just set up an alias in my dns entries?

Actually, I think I have such an alias already (I’ll recheck). But, nginx needs to know about it so when it gets the request it routes it accordingly. I let ghost-cli do the nginx setup and by default it doesn’t do any aliases.


#9

Changed my server block to include
www.theprequel.org
and theprequel.org for both the ssl and non-sll server blocks. This confirms I had the alias setup in dns (though I still should go look and confirm).

But, the browser is a bit unhappy because the URL doesn’t match the URL the certificate—which I think you noted.

So, my question remains? Can I get a certificate that covers both urls? No rush on this. It will keep. I’ll need to set up a several other blogs to handle, too.


#10

Yes, in fact you had one before and then you accidentally replaced it with one that didn’t!

In Certbot you just need to list all of the names with -d options, like -d www.theprequel.org -d theprequel.org, in order to get a single certificate covering all of them. (They also don’t necessarily have to be subdomains of the same registered domain!)


#11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.