Cert now not working - first octet invalid

Help
1

my domain is mypwds.com and a few SANs. I created a cert last night that is not working as prior certs did. This time, I added a bunch of SANs other than the above domain. I hit a few site checkers and got some interesting results, most claim the new cert is ok. However, digicert couldn't connect to the new. They could connect to the old, which is expired.
Old : R10, with SANs www.mypwds.com, mypwds.com
New : R11 with those SANs and several other domains and subdomains.
Here's some output from goDaddy's checker

GoDaddy_2025-03-10
GoDaddy_2025-03-10985×813 88.9 KB

GoDaddy_2024-12-09
GoDaddy_2024-12-09877×781 75 KB

Any ideas?

2

Every tool I used shows your mypwds.com and www subdomain returns an expired cert. And, I don't see a cert with those SANs either.

Have you modified your system since posting here?

These two SSL testers show the same expired cert

3 Likes
3

Sorry Mike, since the new cert is completely non-functional, I return the server to the old cert. I'm playing around with the new one in a dev sandbox and getting this when I enable
System.setProperty("jdk.tls.client.enableStatusRequestExtension", "true");
System.setProperty("com.sun.net.ssl.checkRevocation", "true");

"sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target"
And that is when the validator is working on the R11 from Let's Encrypt.

4

I've put the new cert back and you can see that browsers won't go to it.

5

I see a very unusual problem

First, both SSL Checkers I previously linked successfully validate the newer cert with the extra SANs.

But, an openssl or curl request from my own test server fails.

We'll need to know more about your system. What o/s, what kind of TLS Server is responding, did you do anything with the cert after you got it (like upload to a cert store), and anything else you think is useful.

Also, what ACME Client did you use to get this cert? What version is it?

From my own test server I saw these messages

curl -i https://mypwds.com
curl: (35) error:02000086:rsa routines::last octet invalid

echo|openssl s_client -connect mypwds.com:443 | head -15
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R11
verify return:1
depth=0 CN = mypwds.com
verify return:1
800BF842967E0000:error:02000085:rsa routines:RSA_verify_PKCS1_PSS_mgf1:first octet invalid:../crypto/rsa/rsa_pss.c:76:
800BF842967E0000:error:1C880004:Provider routines:rsa_verify:RSA lib:../providers/implementations/signature/rsa_sig.c:815:
800BF842967E0000:error:0A00007B:SSL routines:tls_process_cert_verify:bad signature:../ssl/statem/statem_lib.c:537:
5 Likes
6

Doubt its related but that looks to be setting up OCSP Stapling. Let's Encrypt is in process of switching from OCSP to CRLs.

4 Likes
7

The server is Ubuntu, though, a sandbox on my Windows machine behaves similarly.
I wrote the Acme client and it has delivered good certs since this time last year, including the expired one that you saw.
I'm using the same server with java's TLS that I have been using for the last year.
In my dev sandbox only :
I noticed from those two comparisons, that OCSP is enabled in the new failing one but NOT in the prior one that worked. So, I put the following configurations in
System.setProperty("jdk.tls.client.enableStatusRequestExtension", "true");
System.setProperty("com.sun.net.ssl.checkRevocation", "true");
Then, I followed code as the revocation check failed.
Looking at your check, I'm wondering about the cert data. Maybe, I botched a file edit BUT goDaddy's checker, and a few others don't seem to find such fault with it.

1 Like
8

Thanks. I'm at the edges of my expertise for what is likely a TLS quirk. But, I've contacted a specialist who will look at it once they get some time. He's in Europe but I'm hoping still today.

There are others here who might know too which is why I changed the title to draw attention to odd error.

3 Likes
9

Thanks! I've continued tracing code and have finally removed some confusing distractions that resulted from my contacting ipinfo and email servers as a client, lol.

1 Like
10

It took me some time to figure this one out - in short: Your server is signing with the wrong private key!

At this time, your service is serving this certificate:

-----BEGIN CERTIFICATE-----
MIIFZjCCBE6gAwIBAgISAyhdBrL32Xe/e1AYjGvmr7foMA0GCSqGSIb3DQEBCwUA
MDMxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQwwCgYDVQQD
EwNSMTEwHhcNMjUwMzEwMDQwMzAwWhcNMjUwNjA4MDQwMjU5WjAVMRMwEQYDVQQD
EwpteXB3ZHMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqF6v
9pUHU1EwV4kn1eMhOek4nhFTL9RpMg6g1EBiFER6Rb/K4uvuJKaVA7chPST7I9cb
8k+L/6JDaZdv/5Nk+yA520WuUjCjpzf35eYkEq7bb6OUidNndORXE/cLjA7R77KC
Y/GSCMGGvJ2TdhASqvm5jHmB+u3w1uHv/d2knp4e4fRwT6b0VJueIF5ff57mz0lC
aus0X9MLVsB9miltsYrtYfcm1dF21jUDQO4XS+JodcAdfgKUe9nPbXOKlcL92z2J
uqesGx0GqtcgtFYZdg+0ibUGx26yskd+KcawQAb+3RouUSbf6SZUddiE9lXop077
vftDim2nY2fc2enQ1QIDAQABo4ICkDCCAowwDgYDVR0PAQH/BAQDAgWgMB0GA1Ud
JQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQW
BBQNfvTh95CBlzCkYy0hznIJ4glt3TAfBgNVHSMEGDAWgBTFz0ak6vTDwHpslcQt
sF6SLybjuTBXBggrBgEFBQcBAQRLMEkwIgYIKwYBBQUHMAGGFmh0dHA6Ly9yMTEu
by5sZW5jci5vcmcwIwYIKwYBBQUHMAKGF2h0dHA6Ly9yMTEuaS5sZW5jci5vcmcv
MIGWBgNVHREEgY4wgYuCDGVpbmVwYXNzLmNvbYIVaGlzdG9yeS5tYW5jZWxvbmEu
bmV0gg1tYW5jZWxvbmEubmV0ggpteXB3ZHMuY29tgg1teXNla3JldHMuY29tghlw
YXNzd29yZHMudGhlc2Fsb25pY2EuY29tgg90aGVzYWxvbmljYS5jb22CDnd3dy5t
eXB3ZHMuY29tMBMGA1UdIAQMMAowCAYGZ4EMAQIBMIIBBAYKKwYBBAHWeQIEAgSB
9QSB8gDwAHYAzPsPaoVxCWX+lZtTzumyfCLphVwNl422qX5UwP5MDbAAAAGVfm34
GwAABAMARzBFAiEAp2uGDNv1aaya3Rlf5QJEFO3WEl05fv7bLaRH6OZIYC8CIE8v
Vzf/DkEVeQtPN2ZNq7bKczKfvweqTRv5Hhz+y1rkAHYAzxFW7tUufK/zh1vZaS6b
6RpxZ0qwF+ysAdJbd87MOwgAAAGVfm34UQAABAMARzBFAiEAxsVKys/k73yNMaOv
S39QW2GSz2M5c6PFBozi3e1IsgkCICZuD/crJqr5TPvMD063Ug+5Z3pwjUpZuT2/
UWmWSSvSMA0GCSqGSIb3DQEBCwUAA4IBAQAo0gIOi6L/a0WmV5zwlGtcUdZ0Y0h0
w9XhiWQq5UVXrAkOhARsHD9OJ/t4P0ps3Mb48PZv5cmaJSC+IumynY4sPg+3m+kE
UPV3qyLeRoJ50pxHxMdCyuz6wICph9o20brpxZA5Q+Uc7lXJR8EbR841CgOaJ/5B
WQB7IUV/6DQbQ437pGZoLC0JAydgIOmkJZ8L0y3GXiNh8x+XQWJqCjhzja43AUGQ
Se3oCPAawyB9Uv+arrAmIocYbHOUB0lLShV83ceyPTf/ehZiaHtzsASdVekQjPHc
BOfOA7Xkzh87ciqDekSCBoybiThuT8Xu26AtCLi6qP4OYijLo48QeZU1
-----END CERTIFICATE-----
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:28:5d:06:b2:f7:d9:77:bf:7b:50:18:8c:6b:e6:af:b7:e8
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=R11
        Validity
            Not Before: Mar 10 04:03:00 2025 GMT
            Not After : Jun  8 04:02:59 2025 GMT
        Subject: CN=mypwds.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a8:5e:af:f6:95:07:53:51:30:57:89:27:d5:e3:
                    21:39:e9:38:9e:11:53:2f:d4:69:32:0e:a0:d4:40:
                    62:14:44:7a:45:bf:ca:e2:eb:ee:24:a6:95:03:b7:
                    21:3d:24:fb:23:d7:1b:f2:4f:8b:ff:a2:43:69:97:
                    6f:ff:93:64:fb:20:39:db:45:ae:52:30:a3:a7:37:
                    f7:e5:e6:24:12:ae:db:6f:a3:94:89:d3:67:74:e4:
                    57:13:f7:0b:8c:0e:d1:ef:b2:82:63:f1:92:08:c1:
                    86:bc:9d:93:76:10:12:aa:f9:b9:8c:79:81:fa:ed:
                    f0:d6:e1:ef:fd:dd:a4:9e:9e:1e:e1:f4:70:4f:a6:
                    f4:54:9b:9e:20:5e:5f:7f:9e:e6:cf:49:42:6a:eb:
                    34:5f:d3:0b:56:c0:7d:9a:29:6d:b1:8a:ed:61:f7:
                    26:d5:d1:76:d6:35:03:40:ee:17:4b:e2:68:75:c0:
                    1d:7e:02:94:7b:d9:cf:6d:73:8a:95:c2:fd:db:3d:
                    89:ba:a7:ac:1b:1d:06:aa:d7:20:b4:56:19:76:0f:
                    b4:89:b5:06:c7:6e:b2:b2:47:7e:29:c6:b0:40:06:
                    fe:dd:1a:2e:51:26:df:e9:26:54:75:d8:84:f6:55:
                    e8:a7:4e:fb:bd:fb:43:8a:6d:a7:63:67:dc:d9:e9:
                    d0:d5
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                0D:7E:F4:E1:F7:90:81:97:30:A4:63:2D:21:CE:72:09:E2:09:6D:DD
            X509v3 Authority Key Identifier:
                C5:CF:46:A4:EA:F4:C3:C0:7A:6C:95:C4:2D:B0:5E:92:2F:26:E3:B9
            Authority Information Access:
                OCSP - URI:http://r11.o.lencr.org
                CA Issuers - URI:http://r11.i.lencr.org/
            X509v3 Subject Alternative Name:
                DNS:einepass.com, DNS:history.mancelona.net, DNS:mancelona.net, DNS:mypwds.com, DNS:mysekrets.com, DNS:passwords.thesalonica.com, DNS:thesalonica.com, DNS:www.mypwds.com
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : CC:FB:0F:6A:85:71:09:65:FE:95:9B:53:CE:E9:B2:7C:
                                22:E9:85:5C:0D:97:8D:B6:A9:7E:54:C0:FE:4C:0D:B0
                    Timestamp : Mar 10 05:01:31.035 2025 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:21:00:A7:6B:86:0C:DB:F5:69:AC:9A:DD:19:
                                5F:E5:02:44:14:ED:D6:12:5D:39:7E:FE:DB:2D:A4:47:
                                E8:E6:48:60:2F:02:20:4F:2F:57:37:FF:0E:41:15:79:
                                0B:4F:37:66:4D:AB:B6:CA:73:32:9F:BF:07:AA:4D:1B:
                                F9:1E:1C:FE:CB:5A:E4
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : CF:11:56:EE:D5:2E:7C:AF:F3:87:5B:D9:69:2E:9B:E9:
                                1A:71:67:4A:B0:17:EC:AC:01:D2:5B:77:CE:CC:3B:08
                    Timestamp : Mar 10 05:01:31.089 2025 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:21:00:C6:C5:4A:CA:CF:E4:EF:7C:8D:31:A3:
                                AF:4B:7F:50:5B:61:92:CF:63:39:73:A3:C5:06:8C:E2:
                                DD:ED:48:B2:09:02:20:26:6E:0F:F7:2B:26:AA:F9:4C:
                                FB:CC:0F:4E:B7:52:0F:B9:67:7A:70:8D:4A:59:B9:3D:
                                BF:51:69:96:49:2B:D2
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        28:d2:02:0e:8b:a2:ff:6b:45:a6:57:9c:f0:94:6b:5c:51:d6:
        74:63:48:74:c3:d5:e1:89:64:2a:e5:45:57:ac:09:0e:84:04:
        6c:1c:3f:4e:27:fb:78:3f:4a:6c:dc:c6:f8:f0:f6:6f:e5:c9:
        9a:25:20:be:22:e9:b2:9d:8e:2c:3e:0f:b7:9b:e9:04:50:f5:
        77:ab:22:de:46:82:79:d2:9c:47:c4:c7:42:ca:ec:fa:c0:80:
        a9:87:da:36:d1:ba:e9:c5:90:39:43:e5:1c:ee:55:c9:47:c1:
        1b:47:ce:35:0a:03:9a:27:fe:41:59:00:7b:21:45:7f:e8:34:
        1b:43:8d:fb:a4:66:68:2c:2d:09:03:27:60:20:e9:a4:25:9f:
        0b:d3:2d:c6:5e:23:61:f3:1f:97:41:62:6a:0a:38:73:8d:ae:
        37:01:41:90:49:ed:e8:08:f0:1a:c3:20:7d:52:ff:9a:ae:b0:
        26:22:87:18:6c:73:94:07:49:4b:4a:15:7c:dd:c7:b2:3d:37:
        ff:7a:16:62:68:7b:73:b0:04:9d:55:e9:10:8c:f1:dc:04:e7:
        ce:03:b5:e4:ce:1f:3b:72:2a:83:7a:44:82:06:8c:9b:89:38:
        6e:4f:c5:ee:db:a0:2d:08:b8:ba:a8:fe:0e:62:28:cb:a3:8f:
        10:79:95:35

(crt.sh is currently down for me - if someone else wants to add the crt.sh links, be my guest)

However, during the TLS handshake, your server is signing the handshake with the private key of this certificate:

-----BEGIN CERTIFICATE-----
MIIE9DCCA9ygAwIBAgISBISsUMHOqliViqcxTWF8q9CyMA0GCSqGSIb3DQEBCwUA
MDMxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQwwCgYDVQQD
EwNSMTAwHhcNMjQxMjA5MjAyNDA1WhcNMjUwMzA5MjAyNDA0WjAVMRMwEQYDVQQD
EwpteXB3ZHMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl8q0
ycs6OrQ4+7OSYEox/47exqbJkvKxqQTgVjag5vnDVDx+l9IRb+E7eAqfY/2TT4MG
Uh2w3OaF2y0lzbg3JekQJFenvhV6v9M8+27qeiuTuNFqe7NYBzWImvRBjkA6HxJd
cpqSjSe9SUkkoC1TY4u4s45v/kBXImMaVw8RVSJvMUESI0ufTEmSGFhC3nxIFkCU
jIZ4D6gu2Ztdzwo56uOH2TkxpexMy+pCp3O06rb0BD6AFUucz22emM31xo4cp4u7
oNeIkg5OfPVqiU3DsG7ST/Pag9gJWyIzm9gQe0vfppRFLo3PUoaqKsQYEisw70Hi
/6I2/MBKErTnFNYPzwIDAQABo4ICHjCCAhowDgYDVR0PAQH/BAQDAgWgMB0GA1Ud
JQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQW
BBTiQ1FdflDBScqqcIlms5Tx3ikMaDAfBgNVHSMEGDAWgBS7vMNHpeS8qcbDpHIM
EI2iNeHI6DBXBggrBgEFBQcBAQRLMEkwIgYIKwYBBQUHMAGGFmh0dHA6Ly9yMTAu
by5sZW5jci5vcmcwIwYIKwYBBQUHMAKGF2h0dHA6Ly9yMTAuaS5sZW5jci5vcmcv
MCUGA1UdEQQeMByCCm15cHdkcy5jb22CDnd3dy5teXB3ZHMuY29tMBMGA1UdIAQM
MAowCAYGZ4EMAQIBMIIBBAYKKwYBBAHWeQIEAgSB9QSB8gDwAHUA3oWB11AkfGvN
y69WN8XngcZM5G7WF2OfjzSnJsnivTcAAAGTrU15cAAABAMARjBEAiBY+IyJlYI7
tybDmCtEm5oIna+XxK2bs9Hz3eJoDYbGbAIgef8TJu0oIams4XPv0Yh/A6W8FikG
h6givRYPmSi/2doAdwCi4wrkRe+9rZt+OO1HZ3dT14JbhJTXK14bLMS5UKRH5wAA
AZOtTXlvAAAEAwBIMEYCIQCc+xbNc7Yew5AOwR5eHaGpSfH7FOVCw84sBKTYTJhZ
wQIhAJqSrROkuzY2tD18UEPL1pI6gYFUPqLxU1dZlybnGU7LMA0GCSqGSIb3DQEB
CwUAA4IBAQBj2wVK4TWaltJQLv7aT6Nob1LFVP7ZuWaNEpd4vD5TG6gaDLK4moZc
QRkjSxssjPgEM/17clE7KH1vPzbiqQlsPhIj0uUIpwH6lw8HyYp+mpe9a5vVS12P
GaOSxmGR1K/U8uNx5i9uF12TuYM5cJW3Jwojr9r23nUcT2tmsV+3fEIX9oMrjN3M
SkGr5g34Dhk6DxNH2ObvfFyky9jJRUjOOnC8Yb5mzaR+17/xP04De1djb0FLGS/w
nAvBH2nzYvLhywCjLqCqdAxzNK9wv+SXmL4jrnLMxQgVMhRyFdHy9OI/K4ZAtLnK
901qt+G+p1yc+AOTIpWF3GMur3+7DPVU
-----END CERTIFICATE-----
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:84:ac:50:c1:ce:aa:58:95:8a:a7:31:4d:61:7c:ab:d0:b2
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=R10
        Validity
            Not Before: Dec  9 20:24:05 2024 GMT
            Not After : Mar  9 20:24:04 2025 GMT
        Subject: CN=mypwds.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:97:ca:b4:c9:cb:3a:3a:b4:38:fb:b3:92:60:4a:
                    31:ff:8e:de:c6:a6:c9:92:f2:b1:a9:04:e0:56:36:
                    a0:e6:f9:c3:54:3c:7e:97:d2:11:6f:e1:3b:78:0a:
                    9f:63:fd:93:4f:83:06:52:1d:b0:dc:e6:85:db:2d:
                    25:cd:b8:37:25:e9:10:24:57:a7:be:15:7a:bf:d3:
                    3c:fb:6e:ea:7a:2b:93:b8:d1:6a:7b:b3:58:07:35:
                    88:9a:f4:41:8e:40:3a:1f:12:5d:72:9a:92:8d:27:
                    bd:49:49:24:a0:2d:53:63:8b:b8:b3:8e:6f:fe:40:
                    57:22:63:1a:57:0f:11:55:22:6f:31:41:12:23:4b:
                    9f:4c:49:92:18:58:42:de:7c:48:16:40:94:8c:86:
                    78:0f:a8:2e:d9:9b:5d:cf:0a:39:ea:e3:87:d9:39:
                    31:a5:ec:4c:cb:ea:42:a7:73:b4:ea:b6:f4:04:3e:
                    80:15:4b:9c:cf:6d:9e:98:cd:f5:c6:8e:1c:a7:8b:
                    bb:a0:d7:88:92:0e:4e:7c:f5:6a:89:4d:c3:b0:6e:
                    d2:4f:f3:da:83:d8:09:5b:22:33:9b:d8:10:7b:4b:
                    df:a6:94:45:2e:8d:cf:52:86:aa:2a:c4:18:12:2b:
                    30:ef:41:e2:ff:a2:36:fc:c0:4a:12:b4:e7:14:d6:
                    0f:cf
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                E2:43:51:5D:7E:50:C1:49:CA:AA:70:89:66:B3:94:F1:DE:29:0C:68
            X509v3 Authority Key Identifier:
                BB:BC:C3:47:A5:E4:BC:A9:C6:C3:A4:72:0C:10:8D:A2:35:E1:C8:E8
            Authority Information Access:
                OCSP - URI:http://r10.o.lencr.org
                CA Issuers - URI:http://r10.i.lencr.org/
            X509v3 Subject Alternative Name:
                DNS:mypwds.com, DNS:www.mypwds.com
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : DE:85:81:D7:50:24:7C:6B:CD:CB:AF:56:37:C5:E7:81:
                                C6:4C:E4:6E:D6:17:63:9F:8F:34:A7:26:C9:E2:BD:37
                    Timestamp : Dec  9 21:22:36.016 2024 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:58:F8:8C:89:95:82:3B:B7:26:C3:98:2B:
                                44:9B:9A:08:9D:AF:97:C4:AD:9B:B3:D1:F3:DD:E2:68:
                                0D:86:C6:6C:02:20:79:FF:13:26:ED:28:21:A9:AC:E1:
                                73:EF:D1:88:7F:03:A5:BC:16:29:06:87:A8:22:BD:16:
                                0F:99:28:BF:D9:DA
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : A2:E3:0A:E4:45:EF:BD:AD:9B:7E:38:ED:47:67:77:53:
                                D7:82:5B:84:94:D7:2B:5E:1B:2C:C4:B9:50:A4:47:E7
                    Timestamp : Dec  9 21:22:36.015 2024 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:46:02:21:00:9C:FB:16:CD:73:B6:1E:C3:90:0E:C1:
                                1E:5E:1D:A1:A9:49:F1:FB:14:E5:42:C3:CE:2C:04:A4:
                                D8:4C:98:59:C1:02:21:00:9A:92:AD:13:A4:BB:36:36:
                                B4:3D:7C:50:43:CB:D6:92:3A:81:81:54:3E:A2:F1:53:
                                57:59:97:26:E7:19:4E:CB
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        63:db:05:4a:e1:35:9a:96:d2:50:2e:fe:da:4f:a3:68:6f:52:
        c5:54:fe:d9:b9:66:8d:12:97:78:bc:3e:53:1b:a8:1a:0c:b2:
        b8:9a:86:5c:41:19:23:4b:1b:2c:8c:f8:04:33:fd:7b:72:51:
        3b:28:7d:6f:3f:36:e2:a9:09:6c:3e:12:23:d2:e5:08:a7:01:
        fa:97:0f:07:c9:8a:7e:9a:97:bd:6b:9b:d5:4b:5d:8f:19:a3:
        92:c6:61:91:d4:af:d4:f2:e3:71:e6:2f:6e:17:5d:93:b9:83:
        39:70:95:b7:27:0a:23:af:da:f6:de:75:1c:4f:6b:66:b1:5f:
        b7:7c:42:17:f6:83:2b:8c:dd:cc:4a:41:ab:e6:0d:f8:0e:19:
        3a:0f:13:47:d8:e6:ef:7c:5c:a4:cb:d8:c9:45:48:ce:3a:70:
        bc:61:be:66:cd:a4:7e:d7:bf:f1:3f:4e:03:7b:57:63:6f:41:
        4b:19:2f:f0:9c:0b:c1:1f:69:f3:62:f2:e1:cb:00:a3:2e:a0:
        aa:74:0c:73:34:af:70:bf:e4:97:98:be:23:ae:72:cc:c5:08:
        15:32:14:72:15:d1:f2:f4:e2:3f:2b:86:40:b4:b9:ca:f7:4d:
        6a:b7:e1:be:a7:5c:9c:f8:03:93:22:95:85:dc:63:2e:af:7f:
        bb:0c:f5:54

The latter is a slightly older certificate that expired yesterday. I'm presuming that your server software is somehow still configured to use the old private key of that certificate, while the actual certificate has since been replaced with a newer certificate.

Usually, server software detects this type of key mismatch automatically, but I guess Java doesn't? Or something else is broken in the Java TLS stack, but it's definetly using the wrong private key from the old cert.

9 Likes
11

Probably why I'm getting : javax.net.ssl.SSLHandshakeException: Received fatal alert: decrypt_error in code trace. Wow, thanks sussing that out. I'm not very sure how it's doing that. I perhaps botched the addition of new certs to the keystore.
Unfortunately, other than the possible corrupted keystore, I can't see how the private key from the prior cert could make its way into the mix with the new cert.
Another plausible theory. Due to bug, I made two CSRs. LE and I may be on different pages in which one got answered.

3 Likes
12

Does the certificate actually match the private key?
Run these commands and make sure both outputs match:

openssl x509 -noout -modulus -in your_cert.pem | openssl md5
openssl rsa -noout -modulus -in your_key.pem | openssl md5

If they don’t match, the wrong private key is in use.

5 Likes
13

Thanks for response. I just went through it again trying to ensure the I kept the private key from the certgen intact and back in the keystore with the certs. BUT, I'm getting the same scenario. So, I will try your advice on commands. Alternatively, I could send my keystore to someone who might be a good second check on it.
(UPDATE: I brake pointed the code where cert is loaded and moduls of private key and cert are different numbers.)
I reiterate that the prior cert worked until expiree yesterday and it was done with the same logic. Now, it still works but for the expiree. The new one is having these
SSLHandshakeExceptionjavax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
SSLHandshakeExceptionjavax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
SSLHandshakeExceptionjavax.net.ssl.SSLHandshakeException: Received fatal alert: decrypt_error
SSLHandshakeExceptionjavax.net.ssl.SSLHandshakeException: Received fatal alert: decrypt_error

14

As @Rip suggested you need to get your private key and cert into a couple of files and verify that the computed public key for your private key match that from the cert. If they match then move onto other debugging, but if they don't match then you are still accidentally using a different private key.

When you request your cert on the finalize step of the ACME process, where you submit a CSR, whatever key is used for the CSR there is the private key that matches the cert issued. You mentioned making a CSR, so presumably your ACME client loads that CSR from a file, so you need to make sure the CSR file was generated using the key you think it was, and not one that's created new during your certificate order process.

You could also just use another ACME client to get a new cert for now, that would rule out client bugs.

6 Likes
15

Update : upon closer scrutiny of process I was able to ensure that secret key matched and certs now function properly. thanks for all the kind responses.

7 Likes
16

Fantastic. And, Happy Cake Day :slight_smile:

5 Likes
17

Thanks, not sure I'll get around to a chunk but maybe. However, trying out my new cert, one issue still remained present that maybe you guys can help with. The SAN domains with the sub other than www were still not supported, at least in chrome.
Update : the 'history' subdomain now works.

18

What is the error Chrome shows? Should see something by clicking the 'unsafe' icon

All the domains validate for me just fine with my own openssl and curl tests plus:

Your domains don't reply on HTTP, just HTTPS

And, HTTPS to einepass redirects to a 404 but that's just your server config

Maybe Chrome has an old cert cached for the not working ones?

2 Likes
19

image
image614×214 15.1 KB

The same server can be configured for each (sub)domain as gleaned from SNI. einepass had not been added to it yet. BUT, the subdomains were, so I'm not sure the preference for success with 'history'. over 'passwords'(perhaps just a timely reload of the cert). Thanks for responding.
Update : it works for passwords.thesalonica.com now.

20

If you click on "Not secure" icon what did it say?

image

2 Likes