Old cert won't die

My old domain, greetonix.com was stolen (as an aside, this could have been prevented if there were a mechanism similar to the CAA record; i.e. only user designated registrars can make changes to the relevant domain name records).

Environment details: I have two machines, one is a physical server at my house (aka “yellow”), the other is a remote VPS (aka “production001”). The old domain was setup on yellow before I bought the VPS. Then I bought the VPS and while attempting to setup/transfer to my new DNS server, the domain name was stolen due to my own lack of alacrity. Then I got a new cert issued for the VPS with the new domain name sweetcious.com

The problem is that when I go to the website with the new domain, it shows the certs for the old domain! I am unable to resolve this.

I ran this command:
on yellow: certbot revoke greetonix.com

It produced this output:
From memory and paraphrased, It asked if I wanted to delete all the related files, I said yes.

certbot certificates on yellow produces:
root@yellow:/etc/bind# certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log


No certs found.


root@yellow:/etc/bind#

My new domain name sweetcious.com works in that a cert was issued.

The same command issued on the VPS gives what appear to be perfectly good results with one exception:
Expiry Date: 2018-12-05 00:38:44+00:00 (INVALID: TEST_CERT)

It seems related to https://github.com/certbot/certbot/issues/3922 as I used --staging many times prior to issuing the real cert.

My web server is (include version): Apache/2.4.18 (Ubuntu)

The operating system my web server runs on is (include version):
Ubuntu 16.04.5 LTS

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): no. bash command line only.

Hi @apb1963

sure? There

https://transparencyreport.google.com/https/certificates?cert_search_auth=&cert_search_cert=&cert_search=include_expired:false;include_subdomains:false;domain:sweetcious.com&lu=cert_search

I can't find a certificate.

https://sweetcious.com/

has the Fake LE - intermediate certificate as issuer, so you installed the certificate from the staging system.

And there is a redirect loop:

download https://sweetcious.com/ -h
SSL-Zertifikat is valide
Strict-Transport-Security: max-age=15768000; includeSubdomains;
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Length: 288
Content-Type: text/html; charset=iso-8859-1
Date: Sun, 09 Sep 2018 16:50:28 GMT
Location: https://sweetcious.com/
Server: Apache/2.4.18 (Ubuntu)

Status: 302 Redirect

https://sweetcious.com/ -> https://sweetcious.com/

First check the redirect section in your apache configuration. Then run Certbot to get a productive certificate.

I'm not sure what do you mean by stolen....
Could you please elaborate on this?

Thank you

Thank you for your response.

I can’t find a certificate.

Well, the following is what prompted me to say the cert was issued:
root@production001:/etc/apache2/sites-available# certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Found the following certs:
Certificate Name: template.sweetcious.com
Domains: template.sweetcious.com dragon.sweetcious.com index.sweetcious.com sweetcious.com www.sweetcious.com
Expiry Date: 2018-12-05 00:38:44+00:00 (INVALID: TEST_CERT)
Certificate Path: /etc/letsencrypt/live/template.sweetcious.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/template.sweetcious.com/privkey.pem


root@production001:/etc/apache2/sites-available#

https://sweetcious.com/ has the Fake LE - intermediate certificate as issuer, so you installed the certificate from the staging system.

Hmm. Not sure about that. I was testing before committing to a real issuance. Is that not the point of --staging? I do not recall moving any certs from one machine to another that I'm aware of.

First check the redirect section in your apache configuration.

wordpress-ssl.conf:RedirectMatch ^((?!.well-known/acme-challenge/).)*$ https://sweetcious.com/

Is that wrong? I'm not sure what's right if so.

Thank you in advance!

My domain name was on the verge of expiring when I found a new webhost/VPS provider. I unlocked my domain in order to transfer authority to my new DNS server at my new webhost/VPS but I had some issues. By the time those issues were resolved, my domain had expired and someone else pointed the root servers at some shady registrar. Therefore, I no longer have access to my domain. Stolen.

This is the TEST_CERT - with Fake LT as Issuer. Productive certificates are logged via

Certificate Transparency

so it's possible to search if a certificate exists. Test-certificates are not logged, so they can't be found.

Staging is the Letsencrypt - testsystem.

If you have a redirect to https://sweetcious.com/ in your ssl-configuration, what happens when this is called with /?

I would expect such a rule in your http - part, not https.

Now you have removed the redirect, so https with the Fake-certificate works.

Create a certificate with the productive system and use that.

I'm not sure why you say that now it works. I still get an error:

sweetcious.com uses an invalid security certificate. The certificate is only valid for the following names: dragon.greetonix.com, greetonix.com, index.greetonix.com, template.greetonix.com, www.greetonix.com The certificate expired on August 11, 2018, 11:44:44 PM GMT-7. The current time is September 10, 2018, 3:33 PM. Error code: SSL_ERROR_BAD_CERT_DOMAIN

I think my confusion stems from the fact that there is both a --staging and a --dry-run; I'm not quite sure of the difference. I left staging enabled with a "wet-run" (the opposite of dry-run) which I think I'm starting to undertand that it issued a test cert. It seems like I need to toggle both options in tandem to get a real cert.

In any event, I will generate the new cert w/out --staging.

A redirect means, that the site is blocked. So if you have a redirect http -> https and then a loop https -> https, you can't create a new certificate with http - 01 - validation.

The certificate is invalide (name, expired, Fake issuer), but this isn't a problem when Letsencrypt want's to validate the file and follows the redirect. But a loop kills that.

So removing the loop is a required step.

The difference, as I understand it, is that --dry-run allows you to test renewal against the staging server without actually keeping or installing the resulting test certificate, whereas --staging just tells certbot to use the staging server but otherwise function as normal.

When I try to create the cert, it tells me “You have an existing certificate that has exactly the same domains or certificate name you requested and isn’t close to expiry.” So I guess I should recreate anyway but I don’t understand why it would work if that message is accurate. Full details follow.

sudo certbot certonly --installer apache --agree-tos --redirect --uir --hsts --staple-ocsp --webroot --webroot-path /usr/local/src/template.sweetcious.com -d template.sweetcious.com --webroot-path /usr/local/src/index.sweetcious.com -d index.sweetcious.com --webroot-path /usr/local/src/dragon.sweetcious.com -d dragon.sweetcious.com --webroot-path /usr/share/wordpress -d sweetcious.com -d www.sweetcious.com --email postmaster@sweetcious.com --rsa-key-size 4096
root 16731 16464 0 15:49 pts/0 00:00:00 grep certbot
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Skipped user interaction because Certbot doesn’t appear to be running in a terminal. You should probably include --non-interactive or --force-interactive on the command line.
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn’t close to expiry.
(ref: /etc/letsencrypt/renewal/template.sweetcious.com.conf)

What would you like to do?


1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)


Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel):

So your webserver doesn’t use this certificate.

Check your certificates with

certbot certificates

to find the full paths and filenames. Then use the certificate.

So now we know that the message is not quite accurate, as the before and after follow:

root@production001:/etc/apache2/sites-enabled# certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Found the following certs:
Certificate Name: template.sweetcious.com
Domains: template.sweetcious.com dragon.sweetcious.com index.sweetcious.com sweetcious.com www.sweetcious.com
Expiry Date: 2018-12-05 00:38:44+00:00 (INVALID: TEST_CERT)
Certificate Path: /etc/letsencrypt/live/template.sweetcious.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/template.sweetcious.com/privkey.pem


root@production001:/etc/apache2/sites-enabled# certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Found the following certs:
Certificate Name: template.sweetcious.com
Domains: template.sweetcious.com dragon.sweetcious.com index.sweetcious.com sweetcious.com www.sweetcious.com
Expiry Date: 2018-12-09 22:14:08+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/template.sweetcious.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/template.sweetcious.com/privkey.pem


Although the cert is now issued, it's still using the old non-existent one.

To wit:
sweetcious.com uses an invalid security certificate. The certificate is only valid for the following names: dragon.greetonix.com, greetonix.com, index.greetonix.com, template.greetonix.com, www.greetonix.com The certificate expired on August 11, 2018, 11:44:44 PM GMT-7. The current time is September 10, 2018, 4:19 PM. Error code: SSL_ERROR_BAD_CERT_DOMAIN

Now you have only a caching problem.

I see the new certificate.

com

1 Like

@apb1963, is it possible that you have an /etc/hosts entry on your local machine that overrides sweetcious.com to point at an outdated host? For instance, if you run curl https://template.sweetcious.com/ on production001, does that work? Or if you access the site from a friend’s computer?

It’s very strange. Normally in Firefox, SHIFT-Refresh forces a new page. However, there were a couple of cookies under the old domain, I deleted them. Then I cleared the cache. Then I refreshed the page. No change. Time to exit out of firefox and see if that works.

I do have an /etc/hosts entry (file generated by SolusVM), however it points to the right IP.

curl outputs what appears to be a page.

Hi,

If your browser does not show the updated certificate, you can always use online certificate checker to check the expiration date of the current certificate your website uses.

Thank you

Thats a good idea.

“Congratulations! This certificate is correctly installed.”

So I guess that sort of resolves the issue in the sense that now the cert is right… I just can’t get my browser to use it!

I suppose this might be a good firefox support question. Thanks to everybody that contributed especially @JuergenAuer

1 Like
template.sweetcious.com.  (insecure)  300  CNAME  sweetcious.com.
sweetcious.com.           (insecure)  300  A      155.94.170.184
sweetcious.com.           (insecure)  300  AAAA   ::1

There’s an IPv6 DNS record for localhost. If you’re running an HTTPS server on your desktop, it will have problems. (If you’re not, clients may fall back to IPv4.)

2 Likes