Multiple certificates conflict

Help
#1

My domain is: underscoredesign.com

I ran this command: certbot --apache -d underscoredesign.com -d www.underscoredesign.com -d portal.underscoredesign.com

It produced this output: created a single certificate with the 3 entries shown above

My web server is (include version): Apache/2.4.37 (centos)

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

My hosting provider, if applicable, is: Digital Ocean

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

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

================================

The first certificate (see below) with root@underscore-centos8 is invalid. It was setup for underscoredesign.com only. The second (valid) certificate serves underscoredesign.com and 2 subdomains. The subdomains use the valid certificate but underscoredesign.com won't release the older, invalid one. The original *.pem keys for the invalid cert were deleted with no backup keys. What to do?

E=root@underscore-centos8, CN=underscore-centos8, O=Unspecified, C=US
16.03.2021
21.03.2022
expires in 366 days underscore-centos8 - 1 entry

Keyalgorithm RSA encryption (2048 bit)
Signatur: SHA256 With RSA-Encryption
Serial Number: 04C92E2F3B9D9CB1
Thumbprint: B7754E6674F7222D58D1882C787627123C330FF1
SHA256 / Certificate: OFVab3I01WoyoQiPf9CnLqDEQAHFl/z0zxFVQZlmLE0=
SHA256 hex / Cert (DANE * 0 1): e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
SHA256 hex / PublicKey (DANE * 1 1): e025a6dea38bb7ec2d162559180fd127ad4c5e42eebcfbfd26402090a4740e7f
SHA256 hex / Subject Public Key Information (SPKI): 7af7d0518a50d9bebef96d538e102c5cc027cd8477c3c7b656222b22065edcc7
SPKI checked via https://v1.pwnedkeys.com/spki-hash: Good: Key isn't compromised
OCSP - Url:
OCSP - must staple: no
Certificate Transparency: no
Enhanced Key Usage: Serverauthentifizierung (1.3.6.1.5.5.7.3.1)

RevocationStatusUnknown: The revocation function was unable to check revocation for the certificate.
OfflineRevocation: The revocation function was unable to check revocation because the revocation server was offline.

E=root@underscore-centos8, CN=underscore-centos8, OU=ca-6022858914402406699, O=Unspecified, C=US
16.03.2021
21.03.2022
expires in 366 days underscore-centos8 - 1 entry

Keyalgorithm RSA encryption (4096 bit)
Signatur: SHA256 With RSA-Encryption
Serial Number: 53957E45AD40112B
Thumbprint: 7F04B17C323C0DCBA9A84C664D958D82A6292B15
SHA256 / Certificate: 8g17sNoVGzzNWwig4smNZrx6J4orLuAxrf8hrkRiDuA=
SHA256 hex / Cert (DANE * 0 1): e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
SHA256 hex / PublicKey (DANE * 1 1): 4743484509bb47358909f0ae03d366def6518d661554baf768038eabee43c94d
SHA256 hex / Subject Public Key Information (SPKI):
SPKI checked via https://v1.pwnedkeys.com/spki-hash: Check unknown. No result 404 / 200
OCSP - Url:
OCSP - must staple: no
Certificate Transparency: no
Enhanced Key Usage:

CN=underscoredesign.com
19.03.2021
17.06.2021
expires in 89 days portal.underscoredesign.com, underscoredesign.com, www.underscoredesign.com - 3 entries

Keyalgorithm RSA encryption (2048 bit)
Signatur: SHA256 With RSA-Encryption
Serial Number: 0333B5D0260A80470F0BC361AE0E0118D7D7
Thumbprint: 8B543C2E52F3F0115C8DF9300F850FAE1428BF7C
SHA256 / Certificate: JuMWhnVDuywnSMfDCBtynLSLBfBpQ4NnPBuOVhex5Ik=
SHA256 hex / Cert (DANE * 0 1): e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
SHA256 hex / PublicKey (DANE * 1 1): 517562ec0c7ed9c0f53b54e76b537eaa6212474384e8bd7609f41002cbe603d1
SHA256 hex / Subject Public Key Information (SPKI): 5621cc297ae696f6547d5c5b16986a05f9cf9f1acb12a7f7f112028c4170594c
SPKI checked via https://v1.pwnedkeys.com/spki-hash: Good: Key isn't compromised
OCSP - Url: http://r3.o.lencr.org
OCSP - must staple: no
Certificate Transparency: yes
Enhanced Key Usage: Serverauthentifizierung (1.3.6.1.5.5.7.3.1), Clientauthentifizierung (1.3.6.1.5.5.7.3.2)

CN=R3, O=Let's Encrypt, C=US
07.10.2020
29.09.2021
expires in 193 days

Keyalgorithm RSA encryption (2048 bit)
Signatur: SHA256 With RSA-Encryption
Serial Number: 400175048314A4C8218C84A90C16CDDF
Thumbprint: 48504E974C0DAC5B5CD476C8202274B24C8C7172
SHA256 / Certificate: cwwb3NhfV85dwLunM+XxulqSWyp3HWQKJvekVCJNrTs=
SHA256 hex / Cert (DANE * 0 1): e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
SHA256 hex / PublicKey (DANE * 1 1): 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
SHA256 hex / Subject Public Key Information (SPKI):
SPKI checked via https://v1.pwnedkeys.com/spki-hash: Check unknown. No result 404 / 200
OCSP - Url:
OCSP - must staple: no
Certificate Transparency: no
Enhanced Key Usage: Serverauthentifizierung (1.3.6.1.5.5.7.3.1), Clientauthentifizierung (1.3.6.1.5.5.7.3.2)

CN=DST Root CA X3, O=Digital Signature Trust Co.
30.09.2000
30.09.2021
expires in 194 days

Keyalgorithm RSA encryption (2048 bit)
Signatur: SHA-1 with RSA Encryption
Serial Number: 44AFB080D6A327BA893039862EF8406B
Thumbprint: DAC9024F54D8F6DF94935FB1732638CA6AD77C13
SHA256 / Certificate: BocmAzGnJAPZCfEF5pvPDTLhvSST/8bZIG0RvNZ3Bzk=
SHA256 hex / Cert (DANE * 0 1): 0687260331a72403d909f105e69bcf0d32e1bd2493ffc6d9206d11bcd6770739
SHA256 hex / PublicKey (DANE * 1 1): 563b3caf8cfef34c2335caf560a7a95906e8488462eb75ac59784830df9e5b2b
SHA256 hex / Subject Public Key Information (SPKI): 29cc40db5e2de462a311cbbafaa1dc466960002335ecdf3317f2cd05c1d0bedf
SPKI checked via https://v1.pwnedkeys.com/spki-hash: Good: Key isn't compromised
OCSP - Url:
OCSP - must staple: no
Certificate Transparency: no
Enhanced Key Usage:

1 Like
#2

Hi @earlofkent,

I think the issue with your site is related to the CentOS Apache "default" VirtualHost, which is given a non-publicly-trusted (self-signed) certificate. Two other people have had this kind of issue recently:

Do the discussions in either of those threads help you with your situation?

I'm wondering why this problem has become common again recently. This problem was very common on CentOS about two years ago, but it seemed that Certbot improvements had largely fixed it, so that it become virtually unknown after that. I wonder if CentOS has somehow changed its defaults recently in a way that makes this problem easier to run into again.

2 Likes
#3

Thank you, Seth. Sorry for the delayed response.. it’s been a rough weekend. Those two links were helpful. It is possible the ServerName set the same as the domain was the culprit. Rather than spend a lot of time trying to hunt down the issue and fix it, I decided to scrap the server and rebuild. Unfortunately, all my impetuous scrambling and testing ran me into Let’s Encrypt’s rate limits, so I have temporarily pointed my site to another of my sites until I can try again.

Thanks again for your assistance.

Kent

1 Like
#4

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