0

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, emailAddress=Mytest@Mytestindia.com
    verify return:1
    depth=0 C=IN, ST=MH, L=Pune, O=Mytest User, OU=Mytest Dev User, CN=MytesteDev.user, emailAddress=Mytest@Mytestgroup.com
    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, emailAddress=Mytest@Mytestgroup.com
    issuer=C=IN, ST=MH, L=Pune, O=Mytest Dev CA, OU=Mytest Dev CA, CN=MytestDevCA.my, emailAddress=Mytest@Mytestindia.com
    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:
Vijay
  • 2,021
  • 4
  • 24
  • 33

1 Answers1

0

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

enter image description here 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.

enter image description here

Vijay
  • 2,021
  • 4
  • 24
  • 33