We have a Google Cloud environment that we inherited from a former 3rd party that managed our websites. This includes a staging environment and a production environment. We have a domain that utilizes several subdomains for customers to have their own personal portal. There was already a SSL cert in place, but has expired. I have installed SNAPD and Certbot on the linux machines and generated a wildcard certificate for the domain. My question is how do you get the site to recognize or point to the new certificate and key locations that LetsEncrypt creates ? I have found documentation for doing this setup, but it is always for a site that was just created. I have no idea how to even find the location of the current expired certificates. I found other documentation that says I need to update the virtual host, but again I cannot find that.
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. crt.sh | 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: truckwarranties1.com
I ran this command:
It produced this output:
My web server is (include version): Apache 2
The operating system my web server runs on is (include version): Debian 9
My hosting provider, if applicable, is: Google Cloud
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
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you're using Certbot): 1.26.0
You probably want to update the Apache configuration files related to those sites. Those configuration files probably contain
Perhaps I misunderstand something but I don't see Apache responding to your domain. I see the openresty server via google. I cannot even connect using HTTPS to look at the cert or server (I get ssl_error_syscall).
curl -I http://truckwarranties.com
HTTP/1.1 200 OK
Date: Fri, 22 Apr 2022 16:07:41 GMT
Via: 1.1 google
(other response headers omitted for brevity)
the domain is truckwarranties1.com
You might want to correct your initial post then
Yeah, like Osiris said, your first post threw me off.
I see you were using a cert from GlobalSign. To find your Apache VirtualHosts start by showing us this command
sudo apachectl -S
You should also re-create your wildcard cert so that it includes the name
truckdomains1.com. Right now the cert would only cover names of X.truckdomains.com (where X is anything) and not just truckdomains1.com
Below is the output from your command. When I requested the cert using certbot, I entered *.truckwarranties1.com as the domain I was requesting it for. Does that not cover it for both the domain and any sub-domain ?
*:80 us-east-1d-staging-vm-vm-vm.c.premium-2000-v2.internal (/etc/apache2/sites-enabled/000-default.conf:1)
*:443 is a NameVirtualHost
default server us-east-1d-staging-vm-vm-vm.c.premium-2000-v2.internal (/etc/apache2/sites-enabled/default-ssl.conf:3)
port 443 namevhost us-east-1d-staging-vm-vm-vm.c.premium-2000-v2.internal (/etc/apache2/sites-enabled/default-ssl.conf:3)
port 443 namevhost us-east-1d-staging-vm-vm-vm.c.premium-2000-v2.internal (/etc/apache2/sites-enabled/default-ssl_backup.conf:3)
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex default: dir="/var/run/apache2/" mechanism=default
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex ssl-cache: using_defaults
User: name="www-data" id=33
Group: name="www-data" id=33
No. You must state each domain name for the cert in the certbot command. It would be helpful to see the command you used.
I see several problems in your Apache conf but I need to step away. Perhaps another volunteer will take over in my absence. I am sure they would be helped by seeing the certbot command you used.
Thanks for the info so far. Below is the command I used.
certbot certonly --manual --preferred-challenges=dns --email email@example.com --server https://acme-v02.api.letsencrypt.org/directory --agree-tos -d *.truckwarranties1.com
Another bit of information. This is a GCP environment with multiple vm's running on a load balancer. For my staging environment, there are two vm's. There is also another site that runs on this machine. https://staging.premium2000.com. It uses a Google managed certificate. Production has four vm's in a load balancer. The production equivalent domain of truckwarranties1.com is heavydutywarranties.com. Production also runs the site https://portal.premium2000.com.
I assume that the Google managed certificates will not be affected by the installation of this certificate ?
I also just tried running the command certbot --apache -v to get more details. It saw the existing certificate and I told it to attempt to reinstall. I got this error back.
- The certificate was saved, but could not be installed (installer: apache). After fixing the error shown below, try installing it again by running:
certbot install --cert-name truckwarranties1.com
Certbot could not find a VirtualHost for *.truckwarranties1.com in the Apache configuration. Please create a VirtualHost with a ServerName matching *.truckwarranties1.com and try again.
Ok, well, there are a lot of moving pieces here which I do not have enough time to help with. A couple things
Your original manual method for certbot gave you a wildcard using the DNS challenge. Just adjust it to this for a cert with both domain names (wildcard and apex). The only change is to add
-d truckwarranties.com on the end (and replace email addr)
certbot certonly --manual --preferred-challenges=dns --email SAMPLE@EMAIL.COM --server https://acme-v02.api.letsencrypt.org/directory --agree-tos -d *.truckwarranties1.com -d truckwarranties1.com
That said, a manual method cannot be automated and will need to be repeated about every 60-75 days as Let's Encrypt certs have a 90 day duration.
Your attempt with the
--apache plug-in is a different thing altogether and won't give you a wildcard cert.
Your Apache config needs work. But, to find where the SSL Certificates are defined look in the file
And, remove this file as it is creating an overlap with the default.ssl.conf file. Even better is to adjust your main apache conf so as to only include *.conf files.
My final comment is I think you need to find someone with Apache expertise to get your site working sensibly again. Maybe another volunteer here will be willing to help you with that but it is well beyond helping you get a cert and towards design and setup of a somewhat complex commercial system.
Thanks Mike. When I look at the default-ssl.conf file, this is what I see. Earlier, I made the change to the SSLCACertificatePath and SSLCACertificateFile. Are these the correct places to be doing this ?
SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile directive is needed.
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
The default-ssl_backup file was one that we just made a copy of so we could revert if needed.
I do agree we need some help. We had a 3rd party managing all of this when I started here last June. We had some issues come up and they decided to part ways with the company, so we inherited all of this. Our goal is to move all of this to another platform, but we will need some assistance along the way.
Thanks again for all of your information!
The Let's Encrypt certs in Apache:
fullchain.pem file from certbot is your
privkey.pem file from certbot is your
Here are some sources for general Apache config. It's at least a place to get started until you can find a complete solution.
I recommend to not use Stapling or HSTS until you fully understand them.
Mozilla SSL Configurator
Official Apache 2.4 SSL How-To
As I already noted, your setup is more than I want to assist with. I am a volunteer who offers my time and expertise for free (as are most of the other helpers here). There are some paid consultants who might be more helpful. schoen and webprofusion are both frequent contributors in this forum.
Thanks Mike. We decided this morning to go with GoDaddy, as they are offering a managed wildcard SSL service. One less thing that we have to deal with. Again, thank you for all of your helpful information. I cannot wait for the day that we move this to a different hosting platform.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.