Sudo certbot renew --dry-run says invalid but not so

I suddenly found my main site was inaccessible saying that the ssl cert was invalid. I ran certbot renew --dry-run and got the following
Attempting to renew cert (gourmetbritain-competition.com) from /etc/letsencrypt/renewal/gourmetbritain-competition.com.conf produced an unexpected error: Problem binding to port 80: Could not bind to IPv4 or IPv6… Skipping.
The following certs could not be renewed:
/etc/letsencrypt/live/bell-computing.com/fullchain.pem (failure)
/etc/letsencrypt/live/gourmetbritain-competition.com/fullchain.pem (failure)

Gourmetbritain-competition.com has no problem. I went ahead and create a new certificate for bell-computing and The following certs were successfully renewed:
/etc/letsencrypt/live/bell-computing.com-0001/fullchain.pem (success)

Now if I test with qualsys its fine. but I still cannot log in. Is this cloudflare’s problem? And did I do right to create a second certificate?

Hi @patbell101

you have created a new certificate bell-computing.com

https://transparencyreport.google.com/https/certificates?cert_search_auth=&cert_search_cert=&cert_search=include_expired:false;include_subdomains:false;domain:bell-computing.com;issuer_uid:4428624498008853827&lu=cert_search

But this certificate isn't installed. Installed is an older Letsencrypt-certificate valid from 2018-04-01 to 2018-06-30, which is now invalide.

The certificate has only two names:

Your older certificate has a lot of alternate names:

DNS-Name: bell-computing.com
DNS-Name: cle-france.bell-computing.com
DNS-Name: cle-france.com
DNS-Name: cle.bell-computing.com
DNS-Name: en.bell-computing.com
DNS-Name: fr.bell-computing.com
DNS-Name: paulmarshallcarpetsandflooring.bell-computing.com
DNS-Name: pmcarpetsandflooring.com
DNS-Name: staging.bell-computing.com
DNS-Name: www.bell-computing.com
DNS-Name: www.cle-france.bell-computing.com
DNS-Name: www.cle-france.com
DNS-Name: www.cle.bell-computing.com
DNS-Name: www.en.bell-computing.com
DNS-Name: www.fr.bell-computing.com

So I did wrong to just create a new certificate then. How do I clear up,this mess? I just tried

sudo certbot renew --allow-subset-of-names

But I haven't resolved the issue. The only certificates I now actuallyneed are the bell-computing, gourmetbritain and pmcarpetsandflooring (www and non www). How do I get a clean start?

I deleted the existing certificates and renewed domain by domain. And once I got it right they all work. Thanks to you all

But now there are some errors.

https://www.cle.bell-computing.com/

has a certificate with gourmetbritain-competition.com, www.gourmetbritain-competition.com, so it’s wrong.

https://pmcarpetsandflooring.com works, but the certificate has CN=sni132912.cloudflaressl.com and has COMODO as Issuer.

Looks like you have some mistakes in your webserver configuration.

Well now I am foxed. I deleted the old certificates and created the new ones as normal. The config files are below for the two serverpilot apps. Everything else was automatic, where is it getting the spurious setting from? I have an nginx/apache Ubuntu 16.04 server what conf files should I look at?

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name
gourmetbritain-competition.com
www.gourmetbritain-competition.com
;

ssl on;

# letsencrypt certificates
ssl_certificate      /etc/letsencrypt/live/gourmetbritain-competition.com/fullchain.pem;
ssl_certificate_key  /etc/letsencrypt/live/gourmetbritain-competition.com/privkey.pem;

    #SSL Optimization
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:20m;
ssl_session_tickets off;

    # modern configuration
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    ssl_prefer_server_ciphers on;


    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK'; 

    # OCSP stapling 
    ssl_stapling on; 
    ssl_stapling_verify on; 

    # verify chain of trust of OCSP response 
    ssl_trusted_certificate /etc/letsencrypt/live/gourmetbritain-competition.com/chain.pem;

    #root directory and logfiles 
    root /srv/users/serverpilot/apps/gourmetbritain/gourmetbritain_nginx/public; 

    access_log /srv/users/serverpilot/log/gourmetbritain/gourmetbritain_nginx.access.log main; 
    error_log /srv/users/serverpilot/log/gourmetbritain/gourmetbritain_nginx.error.log; 

    #proxyset 
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-SSL on; 
    proxy_set_header X-Forwarded-Proto $scheme; 

    #includes 
    include /etc/nginx-sp/vhosts.d/gourmetbritain.d/*.nonssl_conf; 
    include /etc/nginx-sp/vhosts.d/gourmetbritain.d/*.conf; 

}

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name
178.62.53.135
bell-computing.com
www.bell-computing.com
paulmarshallcarpetsandflooring.com
www.paulmarshallcarpetsandflooring.com
staging.bell-computing.com
;

ssl on;

# letsencrypt certificates
ssl_certificate      /etc/letsencrypt/live/bell-computing.com/fullchain.pem;
ssl_certificate_key  /etc/letsencrypt/live/bell-computing.com/privkey.pem;

    #SSL Optimization
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:20m;
ssl_session_tickets off;

    # modern configuration
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    ssl_prefer_server_ciphers on;


    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK'; 

    # OCSP stapling 
    ssl_stapling on; 
    ssl_stapling_verify on; 

    # verify chain of trust of OCSP response 
    ssl_trusted_certificate /etc/letsencrypt/live/bell-computing.com/chain.pem;

    #root directory and logfiles 
    root /srv/users/serverpilot/apps/wordpress/wordpress_nginx/public; 

    access_log /srv/users/serverpilot/log/wordpress/wordpress_nginx.access.log main; 
    error_log /srv/users/serverpilot/log/wordpress/wordpress_nginx.error.log; 

    #proxyset 
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-SSL on; 
    proxy_set_header X-Forwarded-Proto $scheme; 

    #includes 
    include /etc/nginx-sp/vhosts.d/wordpress.d/*.nonssl_conf; 
    include /etc/nginx-sp/vhosts.d/wordpress.d/*.conf; 

}

These two are correct, also bell-computing.com + www.bell-computing.com

But http://www.paulmarshallcarpetsandflooring.com/ has no dns-entry, https://staging.bell-computing.com/ has the wrong certificate (only bell-computing.com, www.bell-computing.com ).

PS: I didn't test all domains, only picked two ( https://www.cle.bell-computing.com/ + https://pmcarpetsandflooring.com ).

PS: There are two different variants:

  1. One host with a lot of domains + a certificate with a lot of names
  2. One domainname (non-www + www) = one host, one certificate with two names

Your older certificate had a lot of names, I prefer (2). But there is no true or false, which version is the better version.

Where are you getting those domains to “test”? Your oreferred method is 2. Thats what I did, I have certificates for two domains each. The okd method 1 cert has been deleted. https://www.cle.bell-computing.com/ is no longer used and http://www.paulmarshallcarpetsandflooring.com/ was in error so neither should exist. There aren’t settings for them in the conf files nor on any certificates now so where are they coming from?

staging.bell-computing.com is a subdomain I plan to use for “staging”

Found the following certs:
Certificate Name: bell-computing.com
Domains: bell-computing.com www.bell-computing.com
Expiry Date: 2018-10-01 11:29:31+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/bell-computing.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/bell-computing.com/privkey.pem
Certificate Name: staging.bell-computing.com
Domains: staging.bell-computing.com
Expiry Date: 2018-10-01 12:24:09+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/staging.bell-computing.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/staging.bell-computing.com/privkey.pem
Certificate Name: pmcarpetsandflooring.com
Domains: pmcarpetsandflooring.com www.pmcarpetsandflooring.com
Expiry Date: 2018-10-01 11:32:36+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/pmcarpetsandflooring.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/pmcarpetsandflooring.com/privkey.pem
Certificate Name: gourmetbritain-competition.com
Domains: gourmetbritain-competition.com www.gourmetbritain-competition.com
Expiry Date: 2018-10-01 12:32:10+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/gourmetbritain-competition.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/gourmetbritain-competition.com/privkey.pem

I found these names in your older certificate - Sudo certbot renew --dry-run says invalid but not so - #2 by JuergenAuer

If these domains are invalid, ok.

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