'openssl clientcertificate not workign for me (TLS1.3)
I am using below command line for openssl
openssl s_server -tls1_3 -state -Verify 1 -key Nexus_Dev.pk8 -cert Nexus_Dev.crt -CAfile NexusDevCA.my.cer -accept 3443 -tlsextdebug
I want to create server requesting client certificate over TLS1.3. First request browser do show prompt for certificate. After selecting certificate it is asking to enter commands on command prompt. I am enterign 'c' which means re-requesting certificate from client. but it is giving me error
8002943DE27F0000:error:0A000117:SSL routines:SSL_verify_client_post_handshake:extension not received:ssl/ssl_lib.c:5848:
I am pasting full output here...Looks like might be some bug in openssl.
vijay@vijay-dev-machine:~/openssl/OpenSSL_1_1_0-stable/apps$ openssl s_server -tls1_3 -state -Verify 1 -key Mytest_Dev.pk8 -cert Mytest_Dev.crt -CAfile MytestDevCA.my.cer -accept 3443 -tlsextdebug
verify depth is 1, must return a certificate
Using default temp DH parameters
ACCEPT
SSL_accept:before SSL initialization
SSL_accept:before SSL initialization
TLS client extension "server name" (id=0), len=14
0000 - 00 0c 00 00 09 6c 6f 63-61 6c 68 6f 73 74 .....localhost
TLS client extension "extended master secret" (id=23), len=0
TLS client extension "renegotiation info" (id=65281), len=1
0000 - 00 .
TLS client extension "supported_groups" (id=10), len=14
0000 - 00 0c 00 1d 00 17 00 18-00 19 01 00 01 01 ..............
TLS client extension "EC point formats" (id=11), len=2
0000 - 01 00 ..
TLS client extension "session ticket" (id=35), len=0
TLS client extension "application layer protocol negotiation" (id=16), len=14
0000 - 00 0c 02 68 32 08 68 74-74 70 2f 31 2e 31 ...h2.http/1.1
TLS client extension "status request" (id=5), len=5
0000 - 01 00 00 00 00 .....
TLS client extension "key share" (id=51), len=107
0000 - 00 69 00 1d 00 20 28 0d-42 4f 38 0b 7b 26 7c 87 .i... (.BO8.{&|.
0010 - d1 82 25 db e6 9e 4d e3-31 9f d2 4e 68 76 bc 5a ..%...M.1..Nhv.Z
0020 - 4c bd f2 55 47 3c 00 17-00 41 04 d8 b0 e9 90 e5 L..UG<...A......
0030 - 3e b4 4e 14 ac 0b b1 5f-9f 11 08 69 e7 58 50 bb >.N...._...i.XP.
0040 - 73 05 33 f2 62 2e 9c 06-6e d1 8b aa cf 3b 91 19 s.3.b...n....;..
0050 - 20 00 44 fa ff 83 8e c4-60 c7 35 fb 5f 3d 8b 71 .D.....`.5._=.q
0060 - 98 de 77 72 80 fc 71 ad-c6 84 06 ..wr..q....
TLS client extension "supported versions" (id=43), len=5
0000 - 04 03 04 03 03 .....
TLS client extension "signature algorithms" (id=13), len=24
0000 - 00 16 04 03 05 03 06 03-08 04 08 05 08 06 04 01 ................
0010 - 05 01 06 01 02 03 02 01- ........
TLS client extension "psk kex modes" (id=45), len=2
0000 - 01 01 ..
TLS client extension "TLS padding" (id=21), len=141
0000 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0010 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0020 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0030 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0040 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0050 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0060 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0070 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0080 - 00 00 00 00 00 00 00 00-00 00 00 00 00 .............
SSL_accept:SSLv3/TLS read client hello
SSL_accept:SSLv3/TLS write server hello
SSL_accept:SSLv3/TLS write change cipher spec
SSL_accept:TLSv1.3 write encrypted extensions
SSL_accept:SSLv3/TLS write certificate request
SSL_accept:SSLv3/TLS write certificate
SSL_accept:TLSv1.3 write server certificate verify
SSL_accept:SSLv3/TLS write finished
SSL_accept:TLSv1.3 early data
SSL_accept:TLSv1.3 early data
depth=1 C=IN, ST=MH, L=Pune, O=Mytest Dev CA, OU=Mytest Dev CA, CN=MytestDevCA.my, [email protected]
verify return:1
depth=0 C=IN, ST=MH, L=Pune, O=Mytest User, OU=Mytest Dev User, CN=MytesteDev.user, [email protected]
verify return:1
SSL_accept:SSLv3/TLS read client certificate
SSL_accept:SSLv3/TLS read certificate verify
SSL_accept:SSLv3/TLS read finished
SSL_accept:SSLv3/TLS write session ticket
SSL_accept:SSLv3/TLS write session ticket
-----BEGIN SSL SESSION PARAMETERS-----
MIIEbwIBAQICAwQEAhMBBCD5VPGfGA+NCKZEvRSuxMNWICu8ebxp5WWDy7hqunSN
kwQgHhjRwB7I/pQCGsXyMXT8iq+KRK4Pu9RscJMXpSgyZPuhBgIEYffGpqIEAgIc
IKOCA/gwggP0MIIC3KADAgECAgMJmZMwDQYJKoZIhvcNAQELBQAwgZQxCzAJBgNV
BAYTAklOMQswCQYDVQQIEwJNSDENMAsGA1UEBxMEUHVuZTEVMBMGA1UEChMMTmV4
dXMgRGV2IENBMRUwEwYDVQQLEwxOZXh1cyBEZXYgQ0ExFjAUBgNVBAMTDU5leHVz
RGV2Q0EubXkxIzAhBgkqhkiG9w0BCQEWFG5leHVzQG5leHVzaW5kaWEuY29tMB4X
.....
K8sr4VeE6ffl6l1OZdWeFtscJnVjqwhNITKRvzAueR/ihV6Teh6U6BzYn9g8qEhw
Y0juXb9GIhW1zcKiIPyPVnM7wSPmv0uVP4t5f4ap/DF9eXFDzMnupa9Locqzt29I
WBP6NrbkAzFO+aEIiaQGBAQBAAAArgcCBQDEKyqFswMCAR0=
-----END SSL SESSION PARAMETERS-----
Client certificate
-----BEGIN CERTIFICATE-----
MIID9DCCAtygAwIBAgIDCZmTMA0GCSqGSIb3DQEBCwUAMIGUMQswCQYDVQQGEwJJ
TjELMAkGA1UECBMCTUgxDTALBgNVBAcTBFB1bmUxFTATBgNVBAoTDE5leHVzIERl
diBDQTEVMBMGA1UECxMMTmV4dXMgRGV2IENBMRYwFAYDVQQDEw1OZXh1c0RldkNB
Lm15MSMwIQYJKoZIhvcNAQkBFhRuZXh1c0BuZXh1c2luZGlhLmNvbTAeFw0yMTEy
MDkwNjUyMDBaFw0yNjEyMDkwNjUyMDBaMIGVMQswCQYDVQQGEwJJTjELMAkGA1UE
.....
BDARBglghkgBhvhCAQEEBAMCB4AwDQYJKoZIhvcNAQELBQADggEBAAjHwWrjojon
mHKRMhVVvEsh3SXNv9sZLUJEbH94QcPa/8+JHMJ5GFVVb5nJE9++qbVjsZLdzvb0
7rMI/+q6w2sLg5WmERmNzk10kXEJyYkH5gSiTHVWbmMHbxsMXze/LAzkpMOtWoId
VgMpyuEWd1vQMEfjZwLK7PYZHC0Ilrj8BIs2HC+WknFN/gG3pGGi5aQzdSvLK+FX
hOn35epdTmXVnhbbHCZ1Y6sITSEykb8wLnkf4oVek3oelOgc2J/YPKhIcGNI7l2/
RiIVtc3CoiD8j1ZzO8Ej5r9LlT+LeX+GqfwxfXlxQ8zJ7qWvS6HKs7dvSFgT+ja2
5AMxTvmhCIk=
-----END CERTIFICATE-----
subject=C=IN, ST=MH, L=Pune, O=Mytest User, OU=Mytest Dev User, CN=MytesteDev.user, [email protected]
issuer=C=IN, ST=MH, L=Pune, O=Mytest Dev CA, OU=Mytest Dev CA, CN=MytestDevCA.my, [email protected]
Shared ciphers:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA
Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA1:RSA+SHA1
Shared Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+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
Supported groups: x25519:secp256r1:secp384r1:secp521r1:ffdhe2048:ffdhe3072
Shared groups: x25519:secp256r1:secp384r1:secp521r1:ffdhe2048:ffdhe3072
CIPHER is TLS_AES_128_GCM_SHA256
This TLS version forbids renegotiation.
GET / HTTP/1.1
Host: localhost:3443
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Cache-Control: max-age=0
c
Failed to initiate request
8002943DE27F0000:error:0A000117:SSL routines:SSL_verify_client_post_handshake:extension not received:ssl/ssl_lib.c:5848:
Solution 1:[1]
I could find reason and posting it for other people help
Certificate Authentication Over TLS1.3
During SSL/TLS handshake server request certificate from client and client respond with certificate. This certificate is used for authentication by server. During handshake browser prompt for certificate. Below is sample snapshot
Selected certificate is submitted by browser to server for authentication purpose.
There is protocol changes in TLS1.3 due to which re-negotiation is not allowed. Protocol change is explained below.
In case of TLS1.3 client must send post_handshake_auth extension in negotiating TLS connection with server. https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.2
for easy reference
4.6.2. Post-Handshake Authentication
When the client has sent the "post_handshake_auth" extension (see
Section 4.2.6), a server MAY request client authentication at any
time after the handshake has completed by sending a
CertificateRequest message. The client MUST respond with the
appropriate Authentication messages (see Section 4.4). If the client
chooses to authenticate, it MUST send Certificate, CertificateVerify,
Rescorla Standards Track [Page 75]
________________________________________
RFC 8446 TLS August 2018
and Finished. If it declines, it MUST send a Certificate message
containing no certificates followed by Finished. All of the client's
messages for a given response MUST appear consecutively on the wire
with no intervening messages of other types.
A client that receives a CertificateRequest message without having
sent the "post_handshake_auth" extension MUST send an
"unexpected_message" fatal alert.
Note: Because client authentication could involve prompting the user,
servers MUST be prepared for some delay, including receiving an
arbitrary number of other messages between sending the
CertificateRequest and receiving a response. In addition, clients
which receive multiple CertificateRequests in close succession MAY
respond to them in a different order than they were received (the
certificate_request_context value allows the server to disambiguate
the responses).
Curently only firefox is supporting enable post handshake auth flag through advanced options. I tried to find similar option for chrome but could not find.
This protocol change is currently supported only by Firefox browser. I could not find anyway to enable above option for anyother browser. This means certificate authentication over TLS1.3 can only be supported only on firefox.
Chome and other browsers might add this feature in future versions.
Certificate Authentication Over TLS1.3
During SSL/TLS handshake server request certificate from client and client respond with certificate. This certificate is used for authentication by server. During handshake browser prompt for certificate. Below is sample snapshot
Selected certificate is submitted by browser to server for authentication purpose.
There is protocol changes in TLS1.3 due to which re-negotiation is not allowed. Protocol change is explained below.
In case of TLS1.3 client must send post_handshake_auth extension in negotiating TLS connection with server. https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.2
for easy reference
4.6.2. Post-Handshake Authentication
When the client has sent the "post_handshake_auth" extension (see Section 4.2.6), a server MAY request client authentication at any time after the handshake has completed by sending a CertificateRequest message. The client MUST respond with the appropriate Authentication messages (see Section 4.4). If the client chooses to authenticate, it MUST send Certificate, CertificateVerify,
Rescorla Standards Track [Page 75]
RFC 8446 TLS August 2018
and Finished. If it declines, it MUST send a Certificate message containing no certificates followed by Finished. All of the client's messages for a given response MUST appear consecutively on the wire with no intervening messages of other types.
A client that receives a CertificateRequest message without having sent the "post_handshake_auth" extension MUST send an "unexpected_message" fatal alert.
Note: Because client authentication could involve prompting the user, servers MUST be prepared for some delay, including receiving an arbitrary number of other messages between sending the CertificateRequest and receiving a response. In addition, clients which receive multiple CertificateRequests in close succession MAY respond to them in a different order than they were received (the certificate_request_context value allows the server to disambiguate the responses).
Curently only firefox is supporting enable post handshake auth flag through advanced options. I tried to find similar option for chrome but could not find.
This protocol change is currently supported only by Firefox browser. I could not find anyway to enable above option for anyother browser. This means certificate authentication over TLS1.3 can only be supported only on firefox.
Chome and other browsers might add this feature in future versions.
Certificate Authentication Over TLS1.3
During SSL/TLS handshake server request certificate from client and client respond with certificate. This certificate is used for authentication by server. During handshake browser prompt for certificate. Below is sample snapshot
Selected certificate is submitted by browser to server for authentication purpose.
There is protocol changes in TLS1.3 due to which re-negotiation is not allowed. Protocol change is explained below.
In case of TLS1.3 client must send post_handshake_auth extension in negotiating TLS connection with server. https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.2
for easy reference
4.6.2. Post-Handshake Authentication
When the client has sent the "post_handshake_auth" extension (see Section 4.2.6), a server MAY request client authentication at any time after the handshake has completed by sending a CertificateRequest message. The client MUST respond with the appropriate Authentication messages (see Section 4.4). If the client chooses to authenticate, it MUST send Certificate, CertificateVerify,
Rescorla Standards Track [Page 75]
RFC 8446 TLS August 2018
and Finished. If it declines, it MUST send a Certificate message containing no certificates followed by Finished. All of the client's messages for a given response MUST appear consecutively on the wire with no intervening messages of other types.
A client that receives a CertificateRequest message without having sent the "post_handshake_auth" extension MUST send an "unexpected_message" fatal alert.
Note: Because client authentication could involve prompting the user, servers MUST be prepared for some delay, including receiving an arbitrary number of other messages between sending the CertificateRequest and receiving a response. In addition, clients which receive multiple CertificateRequests in close succession MAY respond to them in a different order than they were received (the certificate_request_context value allows the server to disambiguate the responses).
Curently only firefox is supporting enable post handshake auth flag through advanced options. I tried to find similar option for chrome but could not find.
This protocol change is currently supported only by Firefox browser. I could not find anyway to enable above option for anyother browser. This means certificate authentication over TLS1.3 can only be supported only on firefox.
Chome and other browsers might add this feature in future versions.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 |