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
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/gitlab.inmusicbrands.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/gitlab.inmusicbrands.com/privkey.pem
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):
Apache/2.4.18
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>
<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
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"
ProxyPreserveHost On
<Proxy *>
Order allow,deny
Allow from all
</Proxy>
ProxyPass / http://172.17.0.3:80/
ProxyPassReverse / http://172.17.0.3:80/
</VirtualHost>
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!