Old cert works, but switching to the new cert says the site is not secure

My domain is: gitlab.inmusicbrands.com

I ran this command:

sudo certbot certonly --apache -d gitlab.inmusicbrands.com

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for gitlab.inmusicbrands.com
Waiting for verification...
Cleaning up challenges

 - Congratulations! Your certificate and chain have been saved at:
   Your key file has been saved at:
   Your cert will expire on 2018-01-11. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"

My web server is (include version):

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

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

Quick history…

  • This server used to run GitLab and Phabricator side-by-side, each running in their own Dockers
  • I use Apache on the actual server as a proxy to the Docker containers (see the vhost below)
  • ~90 days ago, I used certbot to generate certs for 4 subdomains in one go: code, git, gitlab, and svn
  • I’ve had absolutely no issues, getting A+ on almost all the sites (Phabricator for some reason would only give A)
  • Jump to today, certs expire on 10/17 and I’ve moved the code subdomain to another server, so I want to convert the multi-cert to a single cert for the gitlab subdomain only.
  • Run the above commands and get the cert for gitlab subdomain, no issues it seems
  • Change the path in the Apache vhost, reload Apache, then my browser tells me it is unsecure
  • Change the path in Apache vhost back to the original cert path that only has 3 days left, reload, and all is well again

I use the rewrite rule to force any incoming connections on http to https, and the GitLab instance generally does not handle any of the https stuff since it’s through the proxy. I know this configuration works as the current certs are flawless. It seems like this is either an Apache caching issue or something with the way I’m getting the certs. Previously, for the original certs, I used the webroot option. However, the command with the apache plugin seems to complete successfully, so I don’t think this is the problem.

Here’s the vhost. The only line that I change below are the CertFile and CertKeyFile directives. I only change “code” to “gitlab”, and have confirmed that after I run the certbot command, this path does contain the .pem files as expected (with identical permissions, etc. to the original certs).

<VirtualHost *:80>
        ServerName gitlab.inmusicbrands.com
        RewriteEngine On
        RewriteRule ^/(.*) https://gitlab.inmusicbrands.com/$1

<VirtualHost *:443>
        ServerName gitlab.inmusicbrands.com

        SSLEngine On
        SSLCertificateFile /etc/letsencrypt/live/code.inmusicbrands.com/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/code.inmusicbrands.com/privkey.pem
        SSLProtocol All -SSLv2 -SSLv3
        SSLCompression off
        SSLHonorCipherOrder On

        Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"

        ProxyPreserveHost On
        <Proxy *>
                Order allow,deny
                Allow from all
        ProxyPass /
        ProxyPassReverse /

Just to be clear, the current path is for the code subdomain, but the new path should be for the gitlab subdomain. Because this is live, if you check the site now, it should be fine as it is currently pointing to the original (code) cert. I can switch the vhost over to the new cert by request for a limited amount of time if someone needs to get info for debugging.

UPDATE: I resolved my issue. Shortly after I posted this, I saw my apache logs go crazy with requests to “WhyNoPadlock.com”, and decided to give it a go with the old and new certs for comparison. Turns out, I completely forgot to rerun the certbot command without --test-cert. Complete n00b mistake, and all is well now that I have run the command properly!

Your welcome :slight_smile:
That was me running the WhyNoPadLock against your server.
Which it passed “All 22 items called securely!”

Thanks! Marking as the resolution, because awesome :+1:

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