Client certificate provided by let's encrypt does not work

Veuillez remplir les champs ci-dessous pour que nous puissions vous aider. Remarque : vous devez fournir votre nom de domaine pour obtenir de l’aide. Les noms de domaine des certificats émis sont tous rendus publics dans les journaux de Transparence de Certificat (par exemple, crt.sh | example.com). Par conséquent, le fait de ne pas indiquer votre nom de domaine ici n’aide pas à le garder secret, mais rend plus difficile pour nous le fait de vous aider.

Je peux lire des réponses en Anglais : Yes

Mon nom de domaine est : chez.jcz.fr

Mon serveur Web est (inclure la version) : WampServer / Apache 2.4.55

Le système d’exploitation sur lequel mon serveur Web s’exécute est (version incluse) : Windows 10 Pro

Hello let's Encrypt community

To create my pfx, I used the "wacs.exe" tool.
I tested it by doing "openssl s_client -connect chez.jcz.fr:443 -tls1_3".

If I use the "PFX" client certificate (SSLVerifyClient Require in Apache) I have this result:

CONNECTED(000001A8)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = chez.jcz.fr
verify return:1
---
Certificate chain
 0 s:CN = chez.jcz.fr
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA256
   v:NotBefore: Feb 18 00:03:01 2023 GMT; NotAfter: May 19 00:03:00 2023 GMT
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFmzCCBIOgAwIBAgISBHbma5LOGSfgUbuUFsPsO6fEMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMzAyMTgwMDAzMDFaFw0yMzA1MTkwMDAzMDBaMBYxFDASBgNVBAMT
C2NoZXouamN6LmZyMIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEAr32P
8ZqEQkA7b7EYlqNQuUqYTs/0V4q0+FPvphED6lJ3luMaZYs/JaBhlJcx5xGHMjik
yzYJwLr8a0hg+ickb6H2UllhzYDzH9JLH4RL5U3IuOfWw/DIzLXkPyCE3rbESup8
U4xmmTtng3hCtsUBdVQG+8AbJ4tGHLC8xIG6Lzzw5pp2w6dDTB46k2jMQbP0QzqO
khaCKiCGgdmGVepzd+uIizd+2FexfHwi5HpghSiIRUkXvUcrx4XqmPOE2WTyC4Rp
Hv9xaXh+qXuT+MG+AODK6JD4fUr6NZ6Fq2mIOQmO/ZWTP16waKiFavyKYQAJ55wy
kcq/F0DYmkC71C5mlbp6QrCkaSCcYJ0LnfJgmwDBML8/61+49Cby7di6uYAQD0m/
0LGZRDe4mPQNnsDrzC09PEGz/UMtXQ6zgPFOdWPelWzNilUHsUm8jsTGKOxVKAtl
rNkpT9nJV3XfVOI8D4p8Nf72gHnI25YEyVXmuoAdcYmaE1xHwUXc5R8BJe0TAgMB
AAGjggJFMIICQTAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFDjUv1fm8fEE4pXGx7uv
OIIINWjPMB8GA1UdIwQYMBaAFBQusxe3WFbLrlAJQOYfr52LFMLGMFUGCCsGAQUF
BwEBBEkwRzAhBggrBgEFBQcwAYYVaHR0cDovL3IzLm8ubGVuY3Iub3JnMCIGCCsG
AQUFBzAChhZodHRwOi8vcjMuaS5sZW5jci5vcmcvMBYGA1UdEQQPMA2CC2NoZXou
amN6LmZyMEwGA1UdIARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYI
KwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBAwYKKwYBBAHW
eQIEAgSB9ASB8QDvAHUAejKMVNi3LbYg6jjgUh7phBZwMhOFTTvSK8E6V6NS61IA
AAGGYgu7pwAABAMARjBEAiBADDyYqw6AWT0kfSvhAD1qM0YYXaljo2YX6zuEY34V
tgIgDqeHFj5cpvLmkbUGtBDW4LejyHwr5LtaSPoacqe49ZAAdgDoPtDaPvUGNTLn
Vyi8iWvJA9PL0RFr7Otp4Xd9bQa9bgAAAYZiC7uOAAAEAwBHMEUCIQDwfpL0BURh
uu4WTecMXud38mNsybGlFC5tnDXevb48igIga8W8zyN2DmCxBpK6bNQJCtUZPSB3
Zwgv5qYFtBdVm3EwDQYJKoZIhvcNAQELBQADggEBAAI0JS0/oey4dfK3plmabuOz
+7PG/k+GI0vbc4l5FOLKz1pwPXqVL5fLpRtaAnzHcuSfgqu0vdaelmMgFpKlyXfE
nML35QwJLIBstCpWQE9GJWus5bHHU9SLKQ06ZVAerDJ3Wv/PE36FnVibZcW5h9zq
B4IsMxfqIYvwqEPdEP3QMpC4/xRELrysMdnKzp+UTglKw2pt9l8Btzm9ryiW8egG
6AeDa2+On7tL8wDhrFJvrcoO0bxlEuNJPKCUiBKby2aJb4p2IfverAuz1sbxPoLa
5Ylc+V+TOMUtphUdXkis5uK7OsDhFwYthwEDd9Je1j8fN7fp8TsQt2wyrHNFFnA=
-----END CERTIFICATE-----
subject=CN = chez.jcz.fr
issuer=C = US, O = Let's Encrypt, CN = R3
---
Acceptable client certificate CA names
CN = chez.jcz.fr
C = US, O = Let's Encrypt, CN = R3
C = US, O = Internet Security Research Group, CN = ISRG Root X1
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5059 bytes and written 355 bytes
Verification error: unable to get local issuer certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 3072 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 20 (unable to get local issuer certificate)
---
28420000:error:0A00045C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required:ssl\record\rec_layer_s3.c:1600:SSL alert number 116

Press any key to continue...

If I don't use the "PFX" client certificate (SSLVerifyClient None in Apache) I get this result:

CONNECTED(000001B0)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = chez.jcz.fr
verify return:1
---
Certificate chain
 0 s:CN = chez.jcz.fr
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA256
   v:NotBefore: Feb 18 00:03:01 2023 GMT; NotAfter: May 19 00:03:00 2023 GMT
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFmzCCBIOgAwIBAgISBHbma5LOGSfgUbuUFsPsO6fEMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMzAyMTgwMDAzMDFaFw0yMzA1MTkwMDAzMDBaMBYxFDASBgNVBAMT
C2NoZXouamN6LmZyMIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEAr32P
8ZqEQkA7b7EYlqNQuUqYTs/0V4q0+FPvphED6lJ3luMaZYs/JaBhlJcx5xGHMjik
yzYJwLr8a0hg+ickb6H2UllhzYDzH9JLH4RL5U3IuOfWw/DIzLXkPyCE3rbESup8
U4xmmTtng3hCtsUBdVQG+8AbJ4tGHLC8xIG6Lzzw5pp2w6dDTB46k2jMQbP0QzqO
khaCKiCGgdmGVepzd+uIizd+2FexfHwi5HpghSiIRUkXvUcrx4XqmPOE2WTyC4Rp
Hv9xaXh+qXuT+MG+AODK6JD4fUr6NZ6Fq2mIOQmO/ZWTP16waKiFavyKYQAJ55wy
kcq/F0DYmkC71C5mlbp6QrCkaSCcYJ0LnfJgmwDBML8/61+49Cby7di6uYAQD0m/
0LGZRDe4mPQNnsDrzC09PEGz/UMtXQ6zgPFOdWPelWzNilUHsUm8jsTGKOxVKAtl
rNkpT9nJV3XfVOI8D4p8Nf72gHnI25YEyVXmuoAdcYmaE1xHwUXc5R8BJe0TAgMB
AAGjggJFMIICQTAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFDjUv1fm8fEE4pXGx7uv
OIIINWjPMB8GA1UdIwQYMBaAFBQusxe3WFbLrlAJQOYfr52LFMLGMFUGCCsGAQUF
BwEBBEkwRzAhBggrBgEFBQcwAYYVaHR0cDovL3IzLm8ubGVuY3Iub3JnMCIGCCsG
AQUFBzAChhZodHRwOi8vcjMuaS5sZW5jci5vcmcvMBYGA1UdEQQPMA2CC2NoZXou
amN6LmZyMEwGA1UdIARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYI
KwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBAwYKKwYBBAHW
eQIEAgSB9ASB8QDvAHUAejKMVNi3LbYg6jjgUh7phBZwMhOFTTvSK8E6V6NS61IA
AAGGYgu7pwAABAMARjBEAiBADDyYqw6AWT0kfSvhAD1qM0YYXaljo2YX6zuEY34V
tgIgDqeHFj5cpvLmkbUGtBDW4LejyHwr5LtaSPoacqe49ZAAdgDoPtDaPvUGNTLn
Vyi8iWvJA9PL0RFr7Otp4Xd9bQa9bgAAAYZiC7uOAAAEAwBHMEUCIQDwfpL0BURh
uu4WTecMXud38mNsybGlFC5tnDXevb48igIga8W8zyN2DmCxBpK6bNQJCtUZPSB3
Zwgv5qYFtBdVm3EwDQYJKoZIhvcNAQELBQADggEBAAI0JS0/oey4dfK3plmabuOz
+7PG/k+GI0vbc4l5FOLKz1pwPXqVL5fLpRtaAnzHcuSfgqu0vdaelmMgFpKlyXfE
nML35QwJLIBstCpWQE9GJWus5bHHU9SLKQ06ZVAerDJ3Wv/PE36FnVibZcW5h9zq
B4IsMxfqIYvwqEPdEP3QMpC4/xRELrysMdnKzp+UTglKw2pt9l8Btzm9ryiW8egG
6AeDa2+On7tL8wDhrFJvrcoO0bxlEuNJPKCUiBKby2aJb4p2IfverAuz1sbxPoLa
5Ylc+V+TOMUtphUdXkis5uK7OsDhFwYthwEDd9Je1j8fN7fp8TsQt2wyrHNFFnA=
-----END CERTIFICATE-----
subject=CN = chez.jcz.fr
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4823 bytes and written 325 bytes
Verification error: unable to get local issuer certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 3072 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 20 (unable to get local issuer certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 3AFDEA8AE8F89E73E3D675CC5F74E4923F44660F3BC2CF70112C5266FE3A35E4
    Session-ID-ctx:
    Resumption PSK: 629BDFC0064A934A02374E1BE3DC7B3ECC34AC8F5E0981506CCADE40A2DA647B990B29732CFC412B37BCB5D851763319
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 7c c2 7f 52 70 2f b0 59-65 2c 3a 8f 84 38 3c 2f   |..Rp/.Ye,:..8</
    0010 - b5 0f 10 b8 c7 e0 92 9b-5f 5b 03 bf 67 74 ed 06   ........_[..gt..

    Start Time: 1676688013
    Timeout   : 7200 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 1B697E0662C9FA24A061A8F2364396BE6541DD0A53EBE906C974B1F6D243CBC9
    Session-ID-ctx:
    Resumption PSK: AC346AB9ADE759539241423B09D8F98363E2A2BEAD405BE14B3D3B9BAE6559A800D455775C54E381EB9C18725BCB21BA
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - ca c2 d8 34 c0 2f de 65-97 37 ee 68 49 6d 8c c8   ...4./.e.7.hIm..
    0010 - e6 1b d7 e1 76 9c 5c 79-3d a4 61 bf cb 9a 63 9b   ....v.\y=.a...c.

    Start Time: 1676688013
    Timeout   : 7200 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
closed

Press any key to continue...

What is the problem?
Without PFX (SSLVerifyClient None in Apache), I can enter my site "chez.jcz.fr".
What is the problem?

Cordialy.
Artemus24.
@+

This looks like the same question you had on this earlier thread

The short recap is Let's Encrypt certs are not recommended for use with SSLVerifyClient

And, this is not an Apache support forum. You might have better results asking about this Apache feature somewhere else. Bruce's post after the one I linked to here has some suggestions.

5 Likes

Hello Let's Encrypt community.

I get this error message "AH02039: Certificate Verification: Error (2): unable to get issuer certificate" with Let's Encrypt certificate.
Everything happens as if the issuer were no longer valid. I check this by going to the "My" store.
I find three certificates installed:
--> Delivered to: chez.jcz.fr / Delivered by: R3 / expiry date: 05/19/2023 / friendly name: "chez.jcz.fr"
--> Issued at: R3 / Issued by: ISRG Root X1 / expiry date: 09/15/2025 / friendly name: "C=US,O=Let's Encrypt,CN=R3"
--> Issued to: ISRG Root X1 / Issued by: DST Root CA X3 / expiration date: 09/30/2024 / friendly name: "C=US,O=Internet Security Research Group,CN=ISRG Root X1"

First oddity, I don't understand what these "R3" and "ISRG Root X1" certificates are doing in the "My" store?
I only expected to find "chez.jcz.fr".

I consult the "chez.jcz.fr" certificate. It is valid.
The root certificate of "chez.jcz.fr" is "ISRG Root X1" but with a period from 06/04/2015 to 06/04/2035.

Second oddity, it does not correspond to the "ISRG Root X1" certificate that I have in my "My" store, which ends on 09/30/2024.

I am looking at the "ISRG Root X1" certificate from the "my" store.

Third oddity, there is a cross to signify that it is no longer valid.
It says: "The date of this certificate has expired or it is no longer valid.
The period of validity is from 01/20/2021 until 09/30/2024. I don't understand.

Why do I have in my "My" store the "R3" and "ISRG Root X1" certificates?
I check and I have in my store "Trusted Root Certification Authority" these same two certificates.

I consult the ISRG Root X1 certificate which is in the "Trusted Root Certification Authority" store:
--> Issued to: ISRG Root X1 / Issued by: DST Root X / expiry date: 04/06/2035 / friendly name: "ISRG Root X1".
It is valid.

Everything happens as if my certificate "chez.jcz.fr" points to "ISRG Root X1" of the store "my" while this one is invalid.
While I have in my "Trusted Root Certification Authority" store a valid "ISRG Root X1" certificate.

Fourth oddity, if in apache I set "SSLVerifyCient" to "None", I can access my site, the certificate is valid and I have the padlock
I wonder if in this context there was indeed a verification of the issuer.

The strangest thing is that I have no problem with my OpenSSL certificates.

Cordially.
Artemus24.
@+

1 Like

--> The short recap is Let's Encrypt certs are not recommended for use with SSLVerifyClient

In this case, what can they be used for if I cannot identify myself?

Let’s Encrypt offers Domain Validation (DV) certificates.
Does Let’s Encrypt issue certificates for anything other than SSL/TLS for websites?

3 Likes

LetsEncrypt offers DomainValidation Certificates, which simply validates the server is controlled by the domain's registrant.

These certificates are used by the Server/Domain to identify it as securely authenticated when chained against the "Trusted Roots" installed into a client's browser, operating system, or other application/library. This is called "Server Authentication".

SSLVerifyClient is used for "Client Authentication", wherein you secure a resource on the server to only be accessible to the users who can provide a valid certificate. This is almost only used with Corporate or Self-Signed certificates. In this mechanism, you specify a SSLCACertificateFile that is a trusted root for the expected client certificates, and the clients must provide a certificate signed by that CA. There is almost no situation where you would want to use a certificate from a publicly trusted CA for this, because it means anyone who can get a certificate from that CA (LetsEncrypt) can connect to your server. Self-signed or corporate CAs are used, because they can manage who gets valid certificates and who does not. This is usually used to lock down a corporate intranet site to employees, or lock down a server application to a specified list of applications/clients.

2 Likes

Hello and thank you for your explanations, but all that I know.

The client certificate I'm using was not created by OpenSSL.

I used the "wacs.exe" tool to obtain all the certificates for my domain name "chez.jcz.fr".
Let's Encrypt created them, not me. Here is the list of what I get:
--> chez.jcz.fr.pfx
--> chez.jcz.fr-chain.pem
--> chez.jcz.fr-chain-only.pem
--> chez.jcz.fr-chain-cert.pem
--> chez.jcz.fr-chain-key.pem

I store the client certificate "chez.jcz.fr.pfx" in the "my" store.
I associate the other certificates with Apache 2.4.55.

a) why does Let's Encrypt provide me with a client certificate, if it does not work?
If you do not manage this feature, it would be wiser to remove it from your offer.
If not, make sure it works properly.

b) it is indeed about an intranet of which one entrusted to me the implementation of the SSL.

c) the Let's Encrypt certificate is both:
--> Server authentication (1.3.6.1.5.5.7.3.1)
--> Client authentication (1.3.6.1.5.5.7.3.2)
I want to use this client/server relationship in my Apache server. If Let's Encrypt provides me with a client certificate, this feature is operational, right?

d) I am trying to switch MySql to SSL mode. For that, I have to put the "ssl-mode=verify_identity" parameter in the "my.ini" file. If I use an OpenSSL certificate, it will be self-signed and it will be rejected by MySql. MySql specifies that in this context I cannot use a self-signed certificate. If I'm wrong, tell me what to do?

e) I try to use the client certificate provided by Let's Encrypt, but this one is in error when I use "SSLVerifyClient Require" (see above my explanations on the error). Conversely, I don't have this kind of problem with the OpenSSL client certificate I created.
I'm stuck because neither solution (Let's Encrypt or OpenSSL) works. How to solve this problem ?
There is no need to tell me to go to other forums as this has already been done, without success.

f) it seems to me after several checks that the problem comes from a bad certificate authority in the client certificate. My searches by google to solve this problem did not turn up anything. It is to believe that nobody knows how to manage that or that the solution is trivial.

Cordially.
Artremus24.
@

if you are trying to use client certificate, why you expect visits of your site show you a certificate for you?, and what identity you expect from that certificates clients given to you ?

4 Likes

Not Critical
TLS WWW Server Authentication (OID.1.3.6.1.5.5.7.3.1)
TLS WWW Client Authentication (OID.1.3.6.1.5.5.7.3.2)

1 Like

@Artemus24 please read all of the following:

https://www.rfc-editor.org/rfc/rfc5280

and the latest version of CA-Browser-Forum BR (presently 1.8.6) Baseline Requirements Documents (SSL/TLS Server Certificates) – CAB Forum

1 Like

EDIT: @Artemus24 I somehow posted over your comment but was able to revert it. I am sorry.

Short answer: these are not intended to be used as Client Certificates as you are trying to use them, they are primarily intended to be used as Server Certificates. While a LE can be used in some of the contexts you noted and is essentially supported via technological capabilities, they are not intended to be used in your situations and few people lack the experience or desire to troubleshoot implementing anti-patterns.

LetsEncrypt is providing you with a DV Certificate that is primarily intended to be used as a Server Certificate. It is not intended to be used as a Client Certificate in the manner you indicated, but it is supported as a Client Certificate because that usage is applicable in some situations.

If you are securing an Intranet, then you should:

  • create your own Root Certificate and Intermediary
  • install the root certificate in your client computers
  • generate client certificates using the intermediary
  • allocate and track those certificates

You should not be securing a private intranet or resources with a Public CA.

Tools like SmallStep (`step-ca` server) can help you with that and may be your best option.

If you have lesser needs, the MySQL documentation also provides you with clear instructions on how to do this - however they do not use an intermediary CA Certificate. Using an intermediary is a nice touch for convenience, but not required. See https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html

The LetsEncrypt Certificate is an X.509 Certificate that does marks support for those contexts. While it can be used in any applicable context, such as the two OIDs you described, it is not generally used in the context of a Client Certificate because there are more appropriate solutions.

In certain situations, a public DV certificate will be used as a Client Certificate for various operations. This is an exception to standard usage and not the norm. This usage always requires advanced management and configuration as additional ACL measures need to be taken. This usage also requires very strict control measures, as the Private Key must be kept a trusted secret amongst privileged parties in accordance with the Subscriber Agreement and Baseline Requirements. Almost every use-case of Client Certificates for Apache and MySQL are built around them being generated by a private/corporate Certificate Authority, not a Public CA. Regarding these two situations you shared - Apache and MySQL - using a LetsEncrypt or Public CA certificate as a Client Certificate is almost always an anti-pattern.

If you read the documentation for MySQL (one page is linked above), at no point does it suggest using a Public CA such as LetsEncrypt. The documentation instructs you on how to use OpenSSL or MySQL itself to generate a private CA Certificate and client/server certificates signed by it.

I stress this, the MySQL example (https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html) does not use a self-signed certificate.

The official MySQL example uses:

  • A CA Certificate
  • A Server Certificate, signed by the CA Certificate
  • A Client Certificate, signed by the CA Certificate

Regarding verify_identity, consider looking at the docs: https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html

The default setting, --ssl-mode=PREFERRED, produces an encrypted connection if the other default settings are unchanged. However, to help prevent sophisticated man-in-the-middle attacks, it is important for the client to verify the server’s identity. The settings --ssl-mode=VERIFY_CA and --ssl-mode=VERIFY_IDENTITY are a better choice than the default setting to help prevent this type of attack. VERIFY_CA makes the client check that the server’s certificate is valid. VERIFY_IDENTITY makes the client check that the server’s certificate is valid, and also makes the client check that the host name the client is using matches the identity in the server’s certificate. To implement one of these settings, you must first ensure that the CA certificate for the server is reliably available to all the clients that use it in your environment, otherwise availability issues will result. For this reason, they are not the default setting.

ssl-mode is a mysql client setting. please ensure the host name the client is connecting to matches the identity in the server certificate.

4 Likes

Have you tried using "ssl_ca"?
I think it might work if you insert your OpenSSL CA certificate there.

2 Likes

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