The certificate has been validated but the website still unsafe?

Help
1

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:
petble.care

I ran this command:

sudo /opt/bitnami/letsencrypt/lego --path /opt/bitnami/letse ncrypt --email="cs@petblecare.com" --http --http-timeout 30 --http.webroot /opt/bitnami/apps/letsencrypt --dom ains=petble.care renew

It produced this output:
2023/07/19 08:33:36 [INFO] [petble.care] acme: Trying renewal with -393 hours remaining
2023/07/19 08:33:36 [INFO] [petble.care, www.petble.care] acme: Obtaining bundled SAN certificate
2023/07/19 08:33:37 [INFO] [petble.care] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/243307665 617
2023/07/19 08:33:37 [INFO] [www.petble.care] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/24624 8533757
2023/07/19 08:33:37 [INFO] [www.petble.care] acme: authorization already valid; skipping challenge
2023/07/19 08:33:37 [INFO] [petble.care] acme: Could not find solver for: tls-alpn-01
2023/07/19 08:33:37 [INFO] [petble.care] acme: use http-01 solver
2023/07/19 08:33:37 [INFO] [petble.care] acme: Trying to solve HTTP-01
2023/07/19 08:33:43 [INFO] [petble.care] The server validated our request
2023/07/19 08:33:43 [INFO] [petble.care, www.petble.care] acme: Validations succeeded; requesting certificates
2023/07/19 08:33:43 [INFO] [petble.care] Server responded with a certificate.

My web server is (include version):
bitnami, apache2.4.41, PHP 7.3.11

The operating system my web server runs on is (include version):
ubuntu 16.04.4 LTS

My hosting provider, if applicable, is:
amazon ec2 instance

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):
SSH and winscp

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): lego 4.2.0

What happened:
The server has run for about 3 years, it has crontab auto-renew the cert. It didn't happen anything bad on the certificate until this month (3rd July). The renewal procedure didn't work as expected. As the renewed certificate does not work, I have changed the cert to Amazon certification for emergency handling. The renewed let's encrypt cert can be accessed at https://35.73.96.161/ Per now, I run the renew certification procedure manually, it does not have response a the first time, I ctl+c it and run it again, it returns the certain response mentioned the form. So I use IP to check out the website in browser, the certification still not safe.

2

Hi @fenixlam, and welcome to the LE community forum :slight_smile:

That is in dire need of an upgrade.

An LE cert was issued:

See:
crt.sh | 9937866387

I don't know why the server isn't using it.
I don't know much about Bitnami.
Have you tried restarting the server?

4 Likes
3

Using https://35.73.96.161/ the cert will show as not safe. Because the "name" in the URL (your IP) does not match a name in the cert. Using other tools the cert looks fine. It has the name petble.com and the www subdomain and was issued today.

Ignore blurred part below - @rg305 pointed out an error which I fixed in later post

But, your DNS for those domain names do not match to that cert. The root petble.com name points to the below IP and the www domain somewhere else.

When I use your domain names I see completely different certs. A tool like this SSL Checker is very helpful to see the certs used.

nslookup petble.com
Address: 34.193.204.92
Address: 34.193.69.252

And the www subdomain to:

nslookup www.petble.com
www.petble.com  canonical name = proxy-ssl.webflow.com.
proxy-ssl.webflow.com   canonical name = proxy-ssl-geo.webflow.com.
Name:   proxy-ssl-geo.webflow.com
Address: 3.233.126.24
Name:   proxy-ssl-geo.webflow.com
Address: 34.234.52.18
Name:   proxy-ssl-geo.webflow.com
Address: 52.206.163.162
3 Likes
4

? ? ? ?

5 Likes
5

Oh, my bad. Thanks. I saw this in the cert for petble.care and got the .com and .care mixed up

image
image1206×396 22.6 KB

So, petble.care points to 2 different EC2 instances. If an AWS ACM cert works for you why not just use that? Getting Let's Encrypt certs with 2 active servers in DNS is more complex.

The other name in that cert petblecare.com has different DNS for its root and any wildcard name. Do you really intend these to be different? The first is just EC2 but you can see www points to an ELB. Maybe this is what you want but it is not usually what we see.

nslookup petblecare.com
Address: 54.250.101.35

nslookup www.petblecare.com
www.petblecare.com      canonical name = petble-care-production-758500866.ap-northeast-1.elb.amazonaws.com.
Name:   petble-care-production-758500866.ap-northeast-1.elb.amazonaws.com
Address: 52.198.82.38
Name:   petble-care-production-758500866.ap-northeast-1.elb.amazonaws.com
Address: 18.176.38.156
5 Likes
6

the situation is quite complex. I take over this stuff at the beginning of last week. At that time, I only knew the renewal procedure didn't work. In my experience, changing the certificate on Amazon load balancer would be easier than checking the renewal procedure, and I am sure the problem will not happen forever because Amanzon certificate will auto-renew. I have done that twice before, so I am confident about the procedures. That is why I didn't try to run the renewal procedure manually before I moved all the servers from enom's A record into the cname with Aws load balancer.

After I finished all the movement, my colleague points me out that I should try the renewal procedure manually. It is already too late for that. Ha... anyway, I still want to know why the renewal procedure didn't work as expected. It is stuck when I run the renewal procedure at the first time. I stop it forcibly and run it again, it displays the success message. Clearly, it is not that reliable. Anyway, I will discuss with my colleague to keep this setting or roll back the previous setting.

About the server architecture... There are two servers running as production, and two servers are for the same website with different domains. That is why the certificate contains two domains. And www.petblecare.com's index is redirected to petble.care. And the petble.care's order request will redirect to www.petblecare.com. It looks like it is designed for the redirect purpose. And petble.care really didn't have its www version (it will redirect to non-www, I still try to find out why it happen...). When I checked the Aws load balancer, I noticed that the load balancer already has *.petblecare.com certificate. So I created a new certificate for petble.care and put it into Aws application load balaner, so the load balancer has two domains' certificates. They work as my expectation, even though they are on mobile devices.

7

Just looking at petble.care ... the DNS has 2 IP addresses for 2 EC2 instances.

Let me provide an explanation which I am pretty sure is why you get the failures you see:

You are using an HTTP Challenge to request a cert. There are also DNS Challenges and sometimes TLS-ALPN challenges but you are using HTTP.

The lego client creates a file with a special value in the --http.webroot folder. Lego then requests a cert from Let's Encrypt telling it about this file. The LE Server makes an HTTP request to your domain expecting to receive that special value lego created.

Your problem is there are 2 IP addresses. The LE Server might use either IP address to reach you but lego only sets up the server it is running on. There are many ways to deal with this but I just wanted to explain why sometimes it would work and other times not. If the LE Server happens to use the IP for the server lego setup it works. The other IP will not.

There is nothing new about this so I can only guess that your two IP addresses are new and you used to have one. Is that possible?

For HTTP Challenges, every IP (server) in your DNS must be able to respond correctly to the LE Server.

There are several ways to manage the HTTP Challenge in a multi-server setup. There is also a DNS Challenge.

dig A +noall +answer petble.care
petble.care.            45      IN      A       18.176.38.156
petble.care.            45      IN      A       52.198.82.38
6 Likes
8

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