--standalone uses incorrect info from older certificate

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: ired.causeaction.com

I ran this command:
certbot certonly --standalone -d ired.causeaction.com -d iredhost.causeaction.com
It produced this output:
Success - after selecting Replace/Renew option #2
My web server is (include version):
The operating system my web server runs on is (include version):
centos 7

My hosting provider, if applicable, is:

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):
certbot 0.30.2

So when I created the original Cert it was for Host pm1host.causeaction.com and domain ired.causeaction.com. The updated server is currently host=ired.causeaction.com AND domain=ired.causeaction.com.

When I run the certbot certonly --standalone -d ired.causeaction.com -d iredhost.causeaction.com, the new certificate STILL references pm1host.causeaction.com…which makes it invalid. Must I completely remove the OLD certificate to fix the “lingering” incorrect information??

Hi @jkotuby

a certificate has nothing to do with a host name.

Only domain names are relevant.

What does this mean?

Is VestCP really compatible with Certbot?

Sometimes a picture is worth a thousand words. I wish I could paste a screenshot of the Certificate error that Firefox is showing in the certificate viewer.

It is stating
Issued To: pm1host.causeaction.com and
Issued by: pm1host.causeaction.com

Which is no longer valid for this server.
Hmmmm… but it also says that the validity period is Dec 8 2018 to Dec 9 2019.
That can’t be a letsencrypt certificate.

I am now guessing that Apache or Nginx is looking at the wrong certificate… even though Vesta itself may be using the correct certificate.

This isn't a public domain name.

So you may be the only person who sees that error.

I see a "Server not found" message.

1 Like

Correct…it was a public domain in an older version of the same EC2 server…but no longer.
I will have to hunt down which Cert the Web server is looking at. I’m pretty sure that is the problem.

Begin with your local hosts file and then move through DNS, proxies, firewalls, etc.
The site/name you are connecting to should show the same results everywhere on the Internet.

You’re on the right track; you’ll want to search feo SSLCertificate in your Apache configs.

Note that Certbot offers an Apache plugin (–apache instead of --standalone) which handles configuring your wen server automatically. You might find that more user friendly.


Turns out it was a problem with Vesta itself declaring a different certificate.

All set now.

Changing the SSLCertificate entry or using --apache can help here; another alternative is to get Certbot to replace the old certificate in-place with the new one (which never happens automatically when removing names from the certificate). You can do this with certbot certificates (to view information about which certificates Certbot is managing) and certbot --cert-name (to specify which existing certificate to replace when requesting a different set of names).

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