Additional certificate

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:bell-computing.com

I ran this command:$sudo ./letsencrypt-auto certonly --standalone-supported-challenges tls-sni-01 -d paulmarshallcarpetsandflooring.bell-computing.com

It produced this output: a second folder in /etc/letsencrypt/live for paulmarshallcarpetsandflooring.bell-computing.com (I already have several certificates in bell-computing.com at the same level)

My web server is (include version): configured with Nginx as a reverse proxy in front of Apache.

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

My hosting provider, if applicable, is:Digital Ocean

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):no_bell:

I have already installed and use several letsencrypt certificates and need to add more. I think I used the wrong certonly syntax perhaps?

Or do I get the conf file to point to the second chain as well?

I’m not sure I understand your problem.

You asked for a new certificate with one FQDN. You got a new certificate with just one FQDN.

Did you expect something else?

Yes but how do I apply it? There is only one place for the ssl.conf
file and it has

letsencrypt certificates ssl_certificate

/etc/letsencrypt/live/bell-computing.com/fullchain.pem;
ssl_certificate_key
/etc/letsencrypt/live/bell-computing.com/privkey.pem; . . . ||# verify chain of trust of OCSP response ssl_trusted_certificate
/etc/letsencrypt/live/bell-computing.com/chain.pem; How can I include
the contents of the new folder? ie |

/etc/letsencrypt/live/|paulmarshallcarpetsandflooring.bell-computing.com

It may be obvious to you perhaps. I have existing certificates in …bell-computing.com but the new certificate went into a different folder and I don’t get how to add that folder to the ssl.conf file.||||

Does paulmarshallcarpetsandflooring.bell-computing.com have a separate server block in your nginx configuration file? How does paulmarshallcarpetsandflooring.bell-computing.com relate to nginxs configuration file? Is it an alias?

I don’t know what a server block is so probably not, paulmarshall…com is a subdomain of a multisite wordpress network whose root domain is bell-computing.com. I just needed to add another certificate.

My mistake was using --standalone!

sudo certbot certonly --agree-tos --non-interactive --expand --email pat@bell-computing.com --webroot -w /srv/users/serverpilot/apps/wordpress/public -d paulmarshallcarpetsandflooring.bell-computing.com
works just fine!

thanks

I’m glad you got things working, but I’m a little confused about how this relates to the problem that you described before.

The change you made would definitely affect your ability to obtain a certificate from Let’s Encrypt, but earlier in the thread you seemed to agree that you were already able to obtain it, but didn’t know how to install it in your nginx. However, both --standalone and --webroot have in common that they try to obtain a certificate without subsequently installing that certificate in your web server configuration. So, I would expect that you would still have the problem that you would still need to do something else in order to get the newly-issued certificate installed in your web server!

The answer is the difference between “Obtaining” and “Installing”. I had “obtained” it but not “installed” it because I didn’t realise I had used --standalone

Following more than one tutorial (because no one of them exactly matched my setup) led to my confusion.

hth

@schoen’s point was that --webroot also doesn’t install by default.The command you posted will not attempt to install your certificate either.

It did though. See https://paulmarshallcarpetsandflooring.bell-computing.com

No command starting with certonly can modify your web server configuration files—it never runs code that attempts to do that!

Also, https://paulmarshallcarpetsandflooring.bell-computing.com/ gives an error in my browser showing that your certificate is not installed. I think it is instead serving this certificate

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

and not this one

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

Hmm. So how DO I install it? I used --expand to insert it into my existing certificate chain. What I did certainly allows me to develop which it was a problem connecting up to jetpack before and not now. But yes if I use a previously unused browser it does indeed error.

Previously I used the same command to add several certificates and then configured my ssl.conf. I thought the conf lines pointing to the chain files would do the job. I searched long and hard but nothing seems to guide me to actually ADDing further certificates. Hence this post.

What do I do now to install this new one then?

If it helps, below is the content of nginx-sp.ssl.conf which afaicr was all I had to do after running the original certbot command (for the working certificates, eg cle-france.com

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name yourdomain.com www.yourdomain.com;

ssl on;

# letsencrypt certificates
ssl_certificate      /etc/letsencrypt/live/yourdomain/fullchain.pem;
ssl_certificate_key  /etc/letsencrypt/live/yourdomain/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/yourdomain/chain.pem;

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

    access_log /srv/users/serverpilot/log/yourappname/yourappname_nginx.access.log main; 
    error_log /srv/users/serverpilot/log/yourappname/yourappname_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/yourappname.d/*.nonssl_conf; 
    include /etc/nginx-sp/vhosts.d/yourappname.d/*.conf; 

}

Unfortunately, that’s not what --expand means, although it might look like it. --expand means “if the names requested here are a superset of the names covered by an existing certificate, replace that certificate without asking”. It does not expand an existing certificate unless all of the names in that certificate, plus additional names, are mentioned with -d.

In Certbot, only the --apache and --nginx plugins can install certificates for you without requiring you to edit configuration files. If you don’t know of a reason why you can’t use --nginx, perhaps you can do that (which will also get a further certificate).

Otherwise, you’ll have to edit your configuration files. As @Osiris suggested, there should be an HTTPS virtualhost for paulmarshallcarpetsandflooring.bell-computing.com; if there is, you can add a reference to this certificate to it. If there isn’t, you’ll have to add a new server block describing accessing that virtual host via HTTPS.

So, notwithstanding the other advice I have yet to grok, could I run the original certbot certonly command with --expand (below) adding the new site I want to certificate and that would work?

sudo certbot certonly --agree-tos --non-interactive --email pat@bell-computing.com --webroot -w /srv/users/serverpilot/apps/wordpress/public -d bell-computing.com -d www.bell-computing.com -d cle-france.bell-computing.com -d www.cle-france.bell-computing.com -d cle.bell-computing.com -d www.cle.bell-computing.com -d cle-france.com -d www.cle-france.com -d en.bell-computing.com -d www.en.bell-computing.com -d fr.bell-computing.com -d www.fr.bell-computing.com -d staging.bell-computing.com

Yes, that is the intended way to “expand” a certificate.

If that works as you expected, then you should also run certbot certificates to find the extra certificate that is only for paulmarshallcarpetsandflooring.bell-computing.com, and then certbot delete --cert-name whatever to delete it (so that you don’t get errors related to renewal in the future).

I should also note that it would be surprising if all of these different sites had the same webroot directory. Maybe they do initially for testing purposes but then are configured to point at different webroots later on (which is a common pattern leading to renewal failures, because Certbot doesn’t know the right place to put the challenge files for the individual sites during renewal). Normally you want one -w per site, immediately preceding each corresponding -d (unless the different sites in fact serve exactly the same content from exactly the same directory, and will continue to do so in the future).

I’ll try that tomorrow. Its 9pm here.

Thanks for all your help.

Good luck, let us know how it goes!

by the way, this is a wordpress multisite and each certificate is for a subdomain so there IS only one webroot I think.

Anyway, I deleted the old paulmarshall… certificate and ran the certonly superset but it didn’t seem to get the certificate for paulmarshall…

There seems to be an authorisation error with bell-computing.com but I just checked that with Qualys and it seems fine.

Failed authorization procedure. www.bell-computing.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.bell-computing.com/.well-known/acme-challenge/gjuVf3G7gMf8cJKarDCgZqB5u1cxN98Nqq59q0NJVgI: "

<meta http-equiv="Content-Type" content="text/html; char", bell-computing.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://bell-computing.com/.well-known/acme-challenge/bxFelQhnuBE4qt8a015ecXvb2aCAIv2GBiJllZIu-7s: " <meta http-equiv="Content-Type" content="text/html; char"

IMPORTANT NOTES:

The authorization error means that the domain has not completed the http-01 authorization due to a wrong response to the request (http://www.bell-computing.com/.well-known/acme-challenge/gjuVf3G7gMf8cJKarDCgZqB5u1cxN98Nqq59q0NJVgI).

You have to make sure that the challenge files get populated to the correct destination.