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: orgibisph.net
I ran this command:
certbot
It produced this output:
My web server is (include version):
Apache
The operating system my web server runs on is (include version):
ubuntu 24.04
My hosting provider, if applicable, is:
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):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 2.11.0
I can manage my DNS, although am not sure I have best approach.
The domain is orgibisph.net.
I created a cert for svn.orgibisph.net
I used certbot, and it worked fine.
Now I want to create another cert (I think I need to, although perhaps it is down with alternative name) for trac.orgibisph.net
The DNS has A records with the same IP4 address for svn.orgibisph.net and trac.orgibisph.net
I ran sudo certbot --apache --dry-run -d certonly trac.orgibisph.net
and received an okay.
I then ran
sudo certbot -v --apache -d trac.orgibisph.net install
The app asked me if I wanted to install the original cert svn.orgibisph.net.
At that point I hit cancel, because I wasn't sure I was performing the correct action, and did not want to mess up the currently working certificate.
If I selected yes to continue, would it have worked by adding subject alternative name (I think that's the term)?
And would it be better to have an A record for the domain orgibisph.net and then CNAMES for trac and svn?
Thanks for you help. Apologize in advance for not finding the answer and having to ask for help
Thanks for your reply - Correct I never did get a cert for trac I bailed when I tried without --dry-run. The only cert I have is:
Found the following certs:
Certificate Name: svn.orgibisph.net
Serial Number: 4e3c2fc21a20de829aa042885208183528a
Key Type: ECDSA
Domains: svn.orgibisph.net
Expiry Date: 2024-09-14 00:38:38+00:00 (VALID: 80 days)
Certificate Path: /etc/letsencrypt/live/svn.orgibisph.net/fullchain.pem
Private Key Path: /etc/letsencrypt/live/svn.orgibisph.net/privkey.pem
I'll admit I'm a little confused on what command to run as well as output
If I run the following:
sudo certbot certonly --apache --dry-run -d svn.orgibisph.net -d trac.orgibisph.net
Saving debug log to /var/log/letsencrypt/letsencrypt.log
You have an existing certificate that contains a portion of the domains you
requested (ref: /etc/letsencrypt/renewal/svn.orgibisph.net.conf)
Do you want to expand and replace this existing certificate with the new
certificate?
(E)xpand/(C)ancel: E
Simulating renewal of an existing certificate for svn.orgibisph.net and trac.orgibisph.net
The dry run was successful.
If I then run (and this is where I may be doing something wrong)
sudo certbot install --apache -d svn.orgibisph.net -d trac.orgibisph.net
Saving debug log to /var/log/letsencrypt/letsencrypt.log
If I do the certonly, and then expand it.
Do I then just force a renew certificates with something like
--renew-with-new-domains
I guess I'm not sure if I run the cert only to expand the cert, then what do I do,
install and then renew with the --renew-with-new-domains, or am I just confused on what need to be done
Okay, a few things. You don't need to use the second install command when using the --apache plugin. You just repeat the first command without certonly and without --dry-run.
You only need to use certonly as --apache plugin does not support --dry-run on its own. So, that is purely a test command.
BUT, before you do that I think there are more fundamental issues with your Apache config that need to be fixed first. And, it would be helpful to review why you want to combine those two names into one cert. Sometimes it is easier if you keep them separate.
Would you please show output of:
sudo apache2ctl -t -D DUMP_VHOSTS
That will show the active VirtualHosts and their config files and we can go from there.
I say there are problems because your svn subdomain redirects HTTP requests to https://example.com. Literally example.com. That's definitely not correct.
And, your trac subdomain redirects HTTP to HTTPS but you don't have a cert yet for trac so these fail.
I think it's best if we start at the beginning after seeing the Apache dump_vhosts.
VirtualHost configuration:
*:443 is a NameVirtualHost
default server svn.orgibisph.net (/etc/apache2/sites-enabled/svn.orgibisph.net-le-ssl.conf:2)
port 443 namevhost svn.orgibisph.net (/etc/apache2/sites-enabled/svn.orgibisph.net-le-ssl.conf:2)
alias svn.orgibisph.net
port 443 namevhost trac.orgibisph.net (/etc/apache2/sites-enabled/trac.orgibisph.net-ssl.conf:1)
alias trac.orgibisph.net
*:80 is a NameVirtualHost
default server svn.orgibisph.net (/etc/apache2/sites-enabled/svn.orgibisph.net.conf:1)
port 80 namevhost svn.orgibisph.net (/etc/apache2/sites-enabled/svn.orgibisph.net.conf:1)
alias svn.orgibisph.net
port 80 namevhost trac.orgibisph.net (/etc/apache2/sites-enabled/trac.orgibisph.net.conf:1)
alias trac.orgibisph.net
ubuntu@ip-10-0-0-102:/etc/apache2/sites-available$
First, I think it is easier to have a cert for each unique (https) VirtualHost. So, since yours are separate having two certs is easier. Adding names to and removing names from a combined cert is harder than just adding a cert or deleting one. With just a couple names it isn't that much different but as systems grow it can get messy.
How did you already get a VirtualHost on port 443 for your trac subdomain? If you don't have a cert for that name yet what cert did you use in it?
i just made a copy of the trac port 80 virtual host and changed the port. I had done that on the first virtual host as well. When I ran certbot the first time, it created the
svn.orgibisph.net-le-ssl.conf from the existing one that was svn.orgibisph.net.conf. It sound Iike I didn't have to do that. Do you want me to unabel the trac.orgibisph.net-ssl.conf, and stop redirecting port 80, and then try the
sudo certbot certonly --apache -d svn.orgibph.net -d trac.orgibisph.net command?
I recommend disabling the port 443 VirtualHost for trac since you don't have a cert for it yet. It was fine to use svn as base for your trac port 80 VHost but not port 443.
After that just do
sudo certbot --apache -d trac.orgibisph.net
It will get a cert using your port 80 VHost, then create a port 443 VHost using that as a template. That is what you described doing for your other domain so you are just repeating that same process.
That is, this format of the command combines the certonly and the install in one step
I did muck up the redirect permanent - fixed that.
Command ran fine:
sudo certbot --apache -d trac.orgibisph.net
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for trac.orgibisph.net
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/trac.orgibisph.net/fullchain.pem
Key is saved at: /etc/letsencrypt/live/trac.orgibisph.net/privkey.pem
This certificate expires on 2024-09-24.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
Deploying certificate
Some rewrite rules copied from /etc/apache2/sites-enabled/trac.orgibisph.net.conf were disabled in the vhost for your HTTPS site located at /etc/apache2/sites-available/trac.orgibisph.net-le-ssl.conf because they have the potential to create redirection loops.
Successfully deployed certificate for trac.orgibisph.net to /etc/apache2/sites-available/trac.orgibisph.net-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://trac.orgibisph.net
Do I need to have a crontab entry to renew?
If the cert is working, I can do a redirect permanently on both sites to their respective ssl enabled sites, correct?
But --dry-run doesn't issue a "real" certificate, only a testing certificate which it doesn't even store.
Remove the --dry-run to get a "real" certificate.
You probably can expand the existing certificate with this new domain name by adding both hostnames to the command line and with the --expand option. Only ancient software can't deal with a SAN.