Https://www.assentushealth.com/ not working

https://www.assentushealth.com/

Has been working for a few years but now something is wrong with the cert. I tried redo it, but it says "not ready for renewal". There are others certs on the same server that work just fine.

command:

/snap/bin/certbot renew --allow-subset-of-names

Logs:

q2024-01-21 08:08:04,292:DEBUG:certbot._internal.display.obj:Notifying user: Processing /etc/letsencrypt/renewal/assentushealth.com.conf

2024-01-21 08:08:04,435:DEBUG:certbot.ocsp:OCSP response for certificate /etc/letsencrypt/archive/assentushealth.com/cert28.pem is signed by the certificate's issuer.

2024-01-21 08:08:04,438:DEBUG:certbot.ocsp:OCSP certificate status for /etc/letsencrypt/archive/assentushealth.com/cert28.pem is: OCSPCertStatus.GOOD

2024-01-21 08:08:05,015:DEBUG:certbot._internal.display.obj:Notifying user: /etc/letsencrypt/live/assentushealth.com/fullchain.pem expires on 2024-03-31 (skipped)

2024-01-21 15:52:04,378:DEBUG:certbot._internal.display.obj:Notifying user: Processing /etc/letsencrypt/renewal/assentushealth.com.conf

2024-01-21 15:52:04,581:DEBUG:certbot.ocsp:OCSP response for certificate /etc/letsencrypt/archive/assentushealth.com/cert28.pem is signed by the certificate's issuer.

2024-01-21 15:52:04,582:DEBUG:certbot.ocsp:OCSP certificate status for /etc/letsencrypt/archive/assentushealth.com/cert28.pem is: OCSPCertStatus.GOOD

2024-01-21 15:52:05,270:DEBUG:certbot._internal.display.obj:Notifying user: /etc/letsencrypt/live/assentushealth.com/fullchain.pem expires on 2024-03-31 (skipped)

That's to be expected, as it's expiry date is way in the future.

What is your exact issue? Also:

When you opened this thread in the Help section, you should have been provided with a questionnaire. Maybe you didn't get it somehow (which is weird), or you've decided to delete it. In any case, all the answers to this questionnaire are required:


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:

I ran this command:

It produced this output:

My web server is (include version):

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

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

4 Likes

Hi @hal1,

Here is a list of issued certificates crt.sh | assentushealth.com, the latest being 2024-01-01.
That one is unique compared to the rest of the list in that it only has the
Matching Identities of assentushealth.com; all the previous issued certificates have
Matching Identities of assentushealth.com and www.assentushealth.com.

You can check the currently being server certificate for assentushealth.com https://decoder.link/sslchecker/assentushealth.com/443 and is OK.

You can check the currently being server certificate for www.assentushealth.com
https://decoder.link/sslchecker/www.assentushealth.com/443
and see the " Hostname: Doesn't match Common Name or/and SANs".

2 Likes

Interesting! Wonder how that happened? Is that whats causing it?

host www.assentushealth.com
www.assentushealth.com is an alias for assentushealth.com.
assentushealth.com has address 34.70.17.25

Someone requested a certificate that only contains that name instead of renewing the existing certificate. If you want to use both names, the certificate must contain them both. Obtain a new one that contains both names and renew when it is due.

3 Likes

Probably that.

Or, someone issued the below command and there was a failure validating one of the domain names. In that case the cert would be issued but without the failing name.

The --allow-subset-of-names should only be used in carefully controlled circumstances and its results confirmed manually

4 Likes

Fixed now. I think was that it was a very old syntax when it was created. The syntax contained both names originally. Thanks!

4 Likes

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