Question about replacing a wildcard cert

I currently have a Digicert wildcard certificate that is used on several servers.
A website ( - an Apache Guacamole frontend ( - an OpenSSL SFTP server ( and an IIS smtp email forwarder (

What I want to figure our is - Do I want a new wildcard cert? or should I use some other method, and are there any step-by-step docs to replace someone elses ssl cert with a Lets Encrypt one - all of the docs I see are how to install and move from http to https not how to generate and replace an existing https.

Probably not worded well, but hoping I got my idea across

My domain is:
I ran this command:

It produced this output:

My web server is (include version):
multiple - Apache - Nginx and Centos6 OpenSSL for the sftp site
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
Self hosted
I can login to a root shell on my machine (yes or no, or I don’t know):
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):


Welcome. :slightly_smiling_face:

You can always install a new certificate regardless of the CA issuing the certificate. It’s mainly any certificate management software (like certbot) that you might need to watch out for if it’s automatically managing your certificates. You would probably be better off without wildcard certificates if you want to use Let’s Encrypt due to using file-based challenges to prove control over the domains as opposed to using DNS-based challenges required for wildcard certificates. This is because using a client like certbot allows you to automate certificate renewals easily (once it’s properly configured) because the client will manage the challenges for you. It is often much more difficult to manage DNS challenges automatically.

1 Like

I concur with For a fixed set of hostnames, a wildcard cert sounds like overkill. Currently, a wildcard cert indeed requires the dns-01 challenge. While it’s certainly possible to automate this, it does require a compatible DNS hoster with some kind of API. When the requirements are met, even with the dns-01 challenge it can be done easily, but well… All the requiremens would need to be met. Indeed, the http-01 challenge suitable for non-wildcard certs is way more easy.


It looks like several of your Domains are on different machines / IP Addresses.

IMHO, your best option would be to run Certbot on each machine to obtain the certificates only that machine will be using.

If you do a wildcard certificate, or group all the domains into one certificate, you will have to coordinate obtaining the certificate and deploying it onto the relevant machines every 60-90 days. If the domains do not overlap across machines, and each machine is responsible it’s own certificates, you can rely on the automated systems from Certbot to do the renewals for you.


Thank you all - I agree now that the Wildcard is overkill - when we first obtained it, a wildcard was less expensive than individual certificates. That made things easier, as we had sub systems that had frequent name changes. Since our original provider has merged with Digi, the cost from them has skyrocketed. As we are also considering moving many services to AWS (with their included certs) we will probably switch to individuals for the time being.
As to the second part of my question - Any documentation on setting let’sEncrypt and certbot up on a system that is already https? like I mentioned above - everything I’m reading is for taking you from http to https - I don’t want to mess a running system up by using extraneous commands. Or would it be better to just generate the new certs and manually install them (as we did with digi)?

Thank you again

1 Like

Not sure about the documentation part of this, but certbot should be smart enough to detect the current HTTPS VirtualHost and replace the SSLCertificateFile and SSLCertificateKeyFile directives with the new ones. That should replace your certificate without any downtime. Do note that certbot can be a little bit “picky” when it comes to Apache configurations. Too heavily modified custom configurations can be troublesome. For example, every VirtualHost in a single file is (or was? I dunno if it has been fixed) too difficult for certbot unfortunately.

1 Like

Let’s Encrypt discourages manual certificate management in favor of automation for purposes of automatic renewals (hence the relatively-short 90-day validity period of all Let’s Encrypt certificates). Despite this, I manually generate and install certificates for all my websites due to the infrastructure I use, wanting to maintain control over my certificates, and to separate my configuration and operation from the certificate client. This is one of the reasons I developed my own free web-based client for quickly and easily acquiring certificates for manual installation. While @Osiris and others here take issue with this approach, the very reasons @Osiris has stated regarding installation and configuration of an acme client are some of the strongest for an easy, manual approach (lacking permissions and restrictive infrastructure are even stronger reasons). Ultimately, which approach you take is up to you. I guess I’m just a firm believer in the divide-and-conquer approach to isolating issues. I really don’t need my phone and my car to tune my barbecue grill or diagnose my vital signs. The automated approach is obviously superior (once you work out the configuration), but as I mentioned to @ski192man below, if you do decide to continue using wildcard certificates, you will need to use DNS-based challenges, which are often difficult or impossible to automate, which would be a good reason to split the certificates into individual domains, should you decide it wise. Please read more carefully, before bragging about your own client and the such (it’s getting a little bit annoying if you’d ask me): there’s a big difference between getting a certificate issued manually and manually installing a certificate. The former has to be done every 60-90 days, the latter has to be done only once. Hence, there’s not really anything wrong with manually installing a cert.

From what I know about Certbot, I think the best option would remove the configuration for your DigiCert certificates (so that your site is temporarily functional on http only), then run Certbot in the appropriate mode for your webserver software and have it automatically reconfigure your site to use LE certificates. It should be pretty much hands off from there, and you won’t ever need to mess with certificates again.

1 Like


Perhaps I’m not understanding, once you get a new certificate issued (in whatever way), don’t you need to install it afterwards, every time? It could be as simple as copy and paste, but often it’s more involved. I feel like I must be misinterpreting a definition here somehow. For installation, are you meaning “configuration for use” or “putting the certificate where it can be found” or ? I’m meaning the second one.


It seems like they’ve been manually installing wildcard certificates if I’ve understood correctly. Not sure if they could automate a replacement with certbot without going the individual domain/subdomain route, which @dwnewman mentioned was possible with AWS. Would be nice though if they could, especially if the scale of systems is large.

Flag it - that hides. Will work - I’m sure.

1 Like


I’m quite confused.

Certbot can use the apache and nginx installer to install the certificate. This entails generating a new virtualhost configuration file and adding TLS directives to point to the certificate. This is what i mean with installing a certificate: change a configuration file so HTTPS/TLS becomes active.

While this can be done automatically by certbot, some users don’t want certbot to mess with their Apache or nginx configuration file and would like to make the configuration file manually. This also goes for mailservers for example, although I believe there actually is a Postfix plugin.

When someone manually made the configuration files pointing to files in /etc/letsencrypt/live, when the certificate is automatically renewed, the only thing needed after that is a reload of the server to load the newly issued certificate. This reloading can be automated too.

Therefore, this manually installing part only has to be done once. And there’s nothing wrong with that.

1 Like

That makes perfect sense. Thanks for the clarification. I am definitely one of those who prefers not to have my configuration altered for me. Not like I have a choice with many of my webservers anyhow since they are shared hosting (though I suppose it’s happening anyhow with cPanel behind the scenes). :thinking: I guess I consider solutions that simply place the certificate in the correct place during the renewal process as “autoinstalling”, which is really the best possible outcome (when things go correctly). The reloading of the server afterwards to begin serving the new certificate has actually been a frequent oversight around here. There’s currently a topic on which I’ve been working with a guy for a couple of days where his web developer employee left a while back and he may simply need a restart dating back to July! At least we’re hoping that’s all it is. He’s an absolute novice, so I’ve been guiding him carefully as he only responds about once a day.

They don’t need to. If their webserver is modern enough (check, don’t assume), it will support several certificates per virtualhost without any issues.