Expired SSL Certificate Renewal Issue

[stripedsweater]

Good morning lets encrypt community,

I’m running a WordPress site on a Bitnami Stack through GCP on Apache, Debian OS.

I had initially setup My let’s encrypt certificate on another server apart from the one that the site currently operates on, but I just kept the original certificate and key and moved them to my current server. Recently my certificate expired as I hadn’t setup a cron job for auto renewal now when I try to setup another certificate I either get one of these messages in the following format.

---

Command Option 1 Output:

"provide a valid space-separated list of domains for which you wish to configure your web server.

Domain list : WEBSITE.com WEB.WEBSITE.com

A certificate was found at /directory/directory/directory/WEBSITE.com.crt It is registered for a different set of domains: website.com www.website.com. Do you want to disable/revoke the existing certificate and create a new one? [Y/N]: Y

Warning: The domain ‘website.com’ resolves to a different IP address than the one detected for this machine which is ‘11.111.111’. Please fix its DNS entries or remove it.

---

Command Option 2 Output:

(Huge output of callbacks to lets encrypt acme api)

Deactivating auth: https://acme…

Unable to deactivate the authorization: https://acme-…

could not obtain certificates: error: one or more domains had a problem [website.com] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: Cannot negotiate ALPN (cutoff screen) for tls-alpn-01 challenge, url:

---

Question 1:

So, I was wondering if anyone here works at let’s encrypt? If so is there a way you can remove the original record of my domain that was on ‘11.111.11’ IP from the let’s encrypt ssl cert DB, but keep the email that I made the original certificate with so that I could try to create another certificate on my current web-server and potentially create an auto-renew cron job so that I don’t run into this issue in the future?

Also, IDK if the stack that my site is on works with certbot. I tried it on another server with the same stack in the past and it didn’t work . The stack that I’m using comes with its own derivative version called “bncert”.

The reason I care so much about having a fully functional certificate and key on my server is because I want to be pci compliant as this site may have some e-commerce functionality in the future when it goes public.

[_az]

@stripedsweater

If so is there a way you can remove the original record of my domain that was on ‘11.111.11’ IP from the let’s encrypt ssl cert DB

There is no such record. Or, more accurately, there is no such record that influences future certificate requests. Let's Encrypt always does a completely fresh lookup of a domain's IP address. The message you encountered below is one that is a behavior entirely driven by the bncert tool:

@stripedsweater

Warning: The domain ‘website.com’ resolves to a different IP address than the one detected for this machine which is ‘11.111.111’. Please fix its DNS entries or remove it.

@stripedsweater

Also, IDK if the stack that my site is on works with certbot

Yes, Certbot can cause some problems with Bitnami. bncert is the right tool to use (unless you use nginx, in which case they suggest using lego).

The full output of the bncert would be helpful if you wanted help with issuing a certificate for your domain.

[stripedsweater]

@_az

The full output of the bncert would be helpful if you wanted help with issuing a certificate for your domain.

Sorry for being vague.
Command Output 1 was the full output for the bncert command.
Here's a screenshot of a similar output I got after deleting the certificate and key after they expired.

I tried this process multiple times over different servers to see if I would get a different outcome, but it always seemed to be the same. Every time I switched servers I made sure to make a change to the IP in the DNS Records to make sure that the domain was pointing to the right server address.

Command 2 Output was the output to the following command: "sudo /opt/bitnami/letsencrypt/lego --tls --email="EMAIL-ADDRESS" --domains="DOMAIN" --domains="www.DOMAIN" --path="/opt/bitnami/letsencrypt" run"

screenshot

"new users can only post one photo"

@_az

There is no such record. Or, more accurately, there is no such record that influences future certificate requests. Let’s Encrypt always does a completely fresh lookup of a domain’s IP address. The message you encountered below is one that is a behavior entirely driven by the bncert tool

I was really hoping it worked that way even though it would probably be ridiculous to keep a record of that many domains on hand, probably in the millions. Thanks for clarifying!

I think I may have found the cause of the problem and I have found a forum link to a person with a similar issue, but a maybe not so similar solution, as I haven't figured my situation out yet. So, here is what maybe happening that causes this issue according to this stackoverflow post. My domain is registered with google domains and I have it pointing to my webserver that hosts my site, but for some odd reason the domain doesn't appear to be showing the ip of my webserver when I plug it into whatsmydns or when I do a ping test in cmd prompt, it points to multiple IPs, but it still directs traffic to the site's server? According to the stack overflow post I may have to add A & CNAME Records on my domain provider's end as well as on GCP.

I have added said records and I'm currently waiting for a change in the next 48hours. I will try to contact you then with a follow up.

Question 2:

If nothing ends up working. Can I use OpenSSL to create a self-signed certificate for my site or is that frowned upon by the powers that be or the internet in general for pci compliance? I know most certificates come from an accredited certifier like: digicert, that is why I am asking.

Thanks

[stripedsweater]

Output 2

[_az]

@stripedsweater

it points to multiple IPs, but it still directs traffic to the site’s server

Sounds very much like you have configured a "redirect" or "forward" instead of setting up A/CNAME records, or possibly both.

Edit: on second thought, it's even more likely that you are using a CDN like Cloudflare. Is that the case? If you're using Cloudflare, you need to tell lego not to use the TLS-ALPN challenge but use the DNS or HTTP challenge instead. TLS-ALPN is incompatible with CDNs like Cloudflare.

[stripedsweater]

Yes, I am using Cloudflare as a CDN! How do I go about doing that with lego?

I had the A and CNAME Records only on the GCP Side before. I didn't have a "redirect" or "forward" setup in place of those records on my domain provider's side.

After looking further into the subject I've seen that load balancers and CDN's can mess with this Let's Encrypt process.

I myself have yet to add a load balancer, but I am currently using a CDN.

Edit: I checked out the lego documentation on github and found this

CLOUDFLARE_EMAIL=foo@bar.com
CLOUDFLARE_API_KEY=b9841238feb177a84330febba8a83208921177bffe733
lego --dns cloudflare --domains my.domain.com --email my@email.com run

'# or

CLOUDFLARE_DNS_API_TOKEN=1234567890abcdefghijklmnopqrstuvwxyz
lego --dns cloudflare --domains my.domain.com --email my@email.com run

(tried using back ticks but they weren't closing properly)

Two questions:

1. Could this syntax work on my bitnami stack? :

CLOUDFLARE_DNS_API_TOKEN=1234567890abcdefghijklmnopqrstuvwxyz
/opt/bitnami/letsencrypt/lego --dns cloudflare --domains my.domain.com --domains domain.com --email my@email.com --path="/opt/bitnami/letsencrypt" run

2. For "Cloudflare_DNS_API_TOKEN" I would most likely use a custom api token rather than the Global API Key that is used for the entirety of my cloudflare acct that covers multiple domains.

This custom key would need to be an "Edit Zone DNS" Key. Most of the custom api keys require a time to live. This often times is an arbitrary timeline so how long should I set the api key to last as I wouldn't want it to expire before the cert expires as this could potentially cause problems, maybe?

[stripedsweater]

[stripedsweater]

Edit: "new users can only post one photo"

[_az]

I think using lego's Cloudflare API would work fine with Bitnami, yes.

@stripedsweater

use a custom api token rather than the Global API Key

Those limited-scope keys can be a bit tricky to get working, depending on how exactly lego uses Cloudflare's API.

When Cloudflare released the limited-scope keys there were a couple of issues that made them impractical to use, like if you were using a limited-scope key, you couldn't discover the zone ID for a domain. I'm not too sure whether that's been fixed yet.

I'm afraid I don't know know enough about them and how lego uses them to give you a good answer, but the Global API Key should work.

[stripedsweater]

@_az

Edit: on second thought, it’s even more likely that you are using a CDN like Cloudflare. Is that the case? If you’re using Cloudflare, you need to tell lego not to use the TLS-ALPN challenge but use the DNS or HTTP challenge instead. TLS-ALPN is incompatible with CDNs like Cloudflare.

IT WORKED, I LOVE YOU! THANK YOU SO MUCH!!!

For anyone else using Cloudflare as a CDN going through a similar situation in the future here are the steps to fixing this problem.

@_az

use the DNS or HTTP challenge instead. TLS-ALPN is incompatible with CDNs like Cloudflare.

2. Check the Lego Documentation to find your DNS Provider. In this case I am using Cloudflare as a CDN so I chose Cloudflare, although they did not provide me with my domain name.
   b) follow the Lego Docs to create a Cloudflare API Key or Token.

a) Follow the Lego Documentation and cross reference it with the bitnami ssl docs.

(The following method works with both AWS or Google Cloud as long as your using an apache server with a similar deployment. There are also nginx directions in the bitnami ssl docs for those who are interested.)

Follow the ALTERNATIVE APPROACH in the bitnami ssl docs

b) Substitute/Combine

sudo /opt/bitnami/letsencrypt/lego --tls --email="EMAIL-ADDRESS" --domains="DOMAIN" --domains="www.DOMAIN" --path="/opt/bitnami/letsencrypt" run

from the bitnami ssl docs with the code found in the lego documentation for your dns in my case it was the following

CLOUDFLARE_DNS_API_TOKEN=1234567890abcdefghijklmnopqrstuvwxyz \
lego --dns cloudflare --domains my.domain.com --email my@email.com run

then it turned into this

CLOUDFLARE_DNS_API_TOKEN=1234567890abcdefghijklmnopqrstuvwxyz \
lego --dns cloudflare --domains my.domain.com --email my@email.com --path="/opt/bitnami/letsencrypt" run

4. If you received the following message

[INFO] [domainname] acme: Validations succeeded; requesting certificates
[INFO] [domainname] Server responded with a certificate.

Follow the rest of the steps in the bitnami ssl docs in my case it was this:

sudo mv /opt/bitnami/apache2/conf/server.crt /opt/bitnami/apache2/conf/server.crt.old
sudo mv /opt/bitnami/apache2/conf/server.key /opt/bitnami/apache2/conf/server.key.old
sudo mv /opt/bitnami/apache2/conf/server.csr /opt/bitnami/apache2/conf/server.csr.old
sudo ln -sf /opt/bitnami/letsencrypt/certificates/DOMAIN.key /opt/bitnami/apache2/conf/server.key
sudo ln -sf /opt/bitnami/letsencrypt/certificates/DOMAIN.crt /opt/bitnami/apache2/conf/server.crt
sudo chown root:root /opt/bitnami/apache2/conf/server*
sudo chmod 600 /opt/bitnami/apache2/conf/server*

Then I restarted the server

sudo /opt/bitnami/ctlscript.sh restart apache

The end.

https://media1.giphy.com/media/xSM46ernAUN3y/giphy.gif(image larger than 4 MB)