What does this error mean? sslv3 alert certificate unknown:state 23

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

What does this error mean? sslv3 alert certificate unknown:state 23

Blumenthal, Uri - 0553 - MITLL
I use a 3rd-party application that is trying to update itself (so it’s trying to “call home”). Naturally, I’m behind a corporate firewall and Web proxy. The app has been configured to use that proxy. It fails to connect. Packet capture reveals the following:

Handshake failed

The SSL handshake could not be performed.

Host: <remote host name>
Reason: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:state 23:Application response 500 handshakefailed

<Our Service Desk ext. number>
generated 2017-04-24 15:28:13 by webwasher4 
Java/1.8.0_112


I must be dense today (and please, no comment about how this state might be more permanent than that (), but I can’t figure even which peer is complaining. Is it the local end (aka the application) that doesn’t like the proxy’s certificate? Is it the Web proxy that doesn’t like the remote host certificate? Or is it the remote end that doesn’t like the proxy’s certificate?

I can connect to the remote host via browser just fine…

Thanks!

Regards,
Uri Blumenthal
 

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What does this error mean? sslv3 alert certificate unknown:state 23

Viktor Dukhovni

> On Apr 24, 2017, at 5:18 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
>
> I use a 3rd-party application that is trying to update itself (so it’s trying to “call home”). Naturally, I’m behind a corporate firewall and Web proxy. The app has been configured to use that proxy. It fails to connect. Packet capture reveals the following:

You're noticeably at this point in the problem report.  Is this a packet capture
between the application and the proxy, or between the proxy and the outside host?
At what stage of the handshake is the alert seen?

Have you tried using "curl" to complete a proxied connection to the remote server?

> Handshake failed
>
> The SSL handshake could not be performed.
>
> Host: <remote host name>
> Reason: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:state 23:Application response 500 handshakefailed

The alert is always generated remotely and reported locally.  It could
in theory come from the proxy, but more likely from the real remote
server.


> I must be dense today (and please, no comment about how this state might be more permanent than that (), but I can’t figure even which peer is complaining. Is it the local end (aka the application) that doesn’t like the proxy’s certificate? Is it the Web proxy that doesn’t like the remote host certificate? Or is it the remote end that doesn’t like the proxy’s certificate?
>
> I can connect to the remote host via browser just fine

The server may not like the client's ciphers or protocol version.

See my recent post: https://www.spinics.net/lists/openssl-users/msg05623.html
for instructions on how to extract SSL info from PCAP files in a way that
mostly trims away endpoint details... (of course SNI names and cert names
would still be there, so you'd need to trim those if you want to anonymize
the guilty parties).

Capture the traffic between the proxy and the remote server if at all
possible, and compare with the trace between client and proxy.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: What does this error mean? sslv3 alert certificate unknown:state 23

Blumenthal, Uri - 0553 - MITLL
    > I use a 3rd-party application that is trying to update itself (so it’s trying to “call home”).
    > Naturally, I’m behind a corporate firewall and Web proxy. The app has been configured to use
    > that proxy. It fails to connect. Packet capture reveals the following:
   
    You're noticeably at this point in the problem report.  Is this a packet capture
    between the application and the proxy, or between the proxy and the outside host?

It is between the app and the proxy. I have no access to the proxy <-> outside traffic. (

    At what stage of the handshake is the alert seen?

It looks like it’s after the initial handshake (I see HTTP 200 before this).
   
    Have you tried using "curl" to complete a proxied connection to the remote server?

Nope. I don’t even know what to try to “curl” from there, and browser connects fine.

   
    > Handshake failed
    >
    > The SSL handshake could not be performed.
    >
    > Host: <remote host name>
    > Reason: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:state 23:Application response 500 handshakefailed
   
    The alert is always generated remotely and reported locally.  It could
    in theory come from the proxy, but more likely from the real remote
    server.
   
I see, thanks!

   

    The server may not like the client's ciphers or protocol version.
   
    See my recent post: https://www.spinics.net/lists/openssl-users/msg05623.html
    for instructions on how to extract SSL info from PCAP files in a way that
    mostly trims away endpoint details... (of course SNI names and cert names
    would still be there, so you'd need to trim those if you want to anonymize
    the guilty parties).
   
I cannot do “openssl s_client …” because the proxy doesn’t let it through.


    Capture the traffic between the proxy and the remote server if at all
    possible, and compare with the trace between client and proxy.

Alas, cannot. Though I can ask people in charge of the proxy to do that.

I went through the capture between the app (local end) and the proxy. It appears that the sequence is:

ClientHello -> (from app to proxy, with a ton of cipher suites, including 0xc02f)
       <-  ServerHello (with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 – present in ClientHello)
       <- CertificateServer Key Exchange, Server Hello Done (includes proxy’s cert rather than the remote end’s cert)

Alert (Level: Fatal, Description: Certificate Unknown) ->

So it appears that the app expects the remote end’s cert, and is not happy getting the proxy’s cert instead?

 

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What does this error mean? sslv3 alert certificate unknown:state 23

Matt Caswell-2
In reply to this post by Blumenthal, Uri - 0553 - MITLL


On 24/04/17 22:18, Blumenthal, Uri - 0553 - MITLL wrote:

> I use a 3rd-party application that is trying to update itself (so
> it’s trying to “call home”). Naturally, I’m behind a corporate
> firewall and Web proxy. The app has been configured to use that
> proxy. It fails to connect. Packet capture reveals the following:
>
> Handshake failed
>
> The SSL handshake could not be performed.
>
> Host: <remote host name> Reason: error:14094416:SSL
> routines:ssl3_read_bytes:sslv3 alert certificate unknown:state
> 23:Application response 500 handshakefailed
>
> <Our Service Desk ext. number> generated 2017-04-24 15:28:13 by
> webwasher4 Java/1.8.0_112
>

Webwasher is your proxy right? So it is clearly webwasher that is
generating this error message (it says so in the text above!). The
OpenSSL error contained in this text occurs when the remote peer sends a
fatal alert to the local endpoint. So it looks to me like your proxy has
initiated a TLS connection to the remote host but the remote host has
rejected the handshake and sent back a "certificate unknown" fatal alert.

A certificate unknown alert has the following description in the RFCs:

   certificate_unknown
      Some other (unspecified) issue arose in processing the
      certificate, rendering it unacceptable.

So, my guess is that the remote host has requested a client certificate
(i.e. client auth) and your proxy has been unable to provide it.

Matt


>
> I must be dense today (and please, no comment about how this state
> might be more permanent than that (), but I can’t figure even which
> peer is complaining. Is it the local end (aka the application) that
> doesn’t like the proxy’s certificate? Is it the Web proxy that
> doesn’t like the remote host certificate? Or is it the remote end
> that doesn’t like the proxy’s certificate?
>
> I can connect to the remote host via browser just fine…
>
> Thanks! — Regards, Uri Blumenthal
>
>
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: What does this error mean? sslv3 alert certificate unknown:state 23

Blumenthal, Uri - 0553 - MITLL
    > Handshake failed
    >
    > The SSL handshake could not be performed.
    >
    > Host: <remote host name> Reason: error:14094416:SSL
    > routines:ssl3_read_bytes:sslv3 alert certificate unknown:state
    > 23:Application response 500 handshakefailed
    >
    > <Our Service Desk ext. number>
    > generated 2017-04-24 15:28:13 by webwasher4
    > Java/1.8.0_112
   
    Webwasher is your proxy right?

Yes. (


    So it is clearly webwasher that is
    generating this error message (it says so in the text above!). The
    OpenSSL error contained in this text occurs when the remote peer sends a
    fatal alert to the local endpoint. So it looks to me like your proxy has
    initiated a TLS connection to the remote host but the remote host has
    rejected the handshake and sent back a "certificate unknown" fatal alert.
   
    A certificate unknown alert has the following description in the RFCs:
   
       certificate_unknown
          Some other (unspecified) issue arose in processing the
          certificate, rendering it unacceptable.
   
    So, my guess is that the remote host has requested a client certificate
    (i.e. client auth) and your proxy has been unable to provide it.
   
Understood, thanks!

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What does this error mean? sslv3 alert certificate unknown:state 23

Viktor Dukhovni
In reply to this post by Blumenthal, Uri - 0553 - MITLL

> On Apr 24, 2017, at 6:11 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
>
> I went through the capture between the app (local end) and the proxy. It appears that the sequence is:
>
> ClientHello -> (from app to proxy, with a ton of cipher suites, including 0xc02f)
>       <-  ServerHello (with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 – present in ClientHello)
>       <- CertificateServer Key Exchange, Server Hello Done (includes proxy’s cert rather than the remote end’s cert)
>
> Alert (Level: Fatal, Description: Certificate Unknown) ->
>
> So it appears that the app expects the remote end’s cert, and is not happy getting the proxy’s cert instead?

Please report tshark output, not an approximate rendition.  In what direction
is the alert sent?

It is indeed possible that the application is not configured for and correctly
rejects the forged certificate of the MiTM proxy.  It would need the Root CA
of the proxy as a trusted issuer, but that may not be configurable.  In which
case you'd need to let the app connect directly to the remote server without
an MiTM-proxy.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: What does this error mean? sslv3 alert certificate unknown:state 23

Blumenthal, Uri - 0553 - MITLL
    > I went through the capture between the app (local end) and the proxy. It appears that the sequence is:
    >
    > ClientHello -> (from app to proxy, with a ton of cipher suites, including 0xc02f)
    >       <-  ServerHello (with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 – present in ClientHello)
    >       <- CertificateServer Key Exchange, Server Hello Done (includes proxy’s cert rather than the remote end’s cert)
    >
    > Alert (Level: Fatal, Description: Certificate Unknown) ->
    >
    > So it appears that the app expects the remote end’s cert, and is not happy getting the proxy’s cert instead?
   
    Please report tshark output, not an approximate rendition.  In what direction
    is the alert sent?

I’m using WireShark. The IP addresses on the Alert packet show local host as the source, and the proxy as the destination. Is there another way to tell the direction? Or how to present it in a way that I can sanitize the output and post here?

In response to this Alert packet I see two packets from the proxy to the local host:
- [ACK]
- [PSH, ACK]

And then from the local host to the proxy:
- [FIN, ACK]
- [RST]
- [RST]


   
    It is indeed possible that the application is not configured for and correctly
    rejects the forged certificate of the MiTM proxy.  It would need the Root CA
    of the proxy as a trusted issuer, but that may not be configurable.  In which
    case you'd need to let the app connect directly to the remote server without
    an MiTM-proxy.

Understood, thanks!

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What does this error mean? sslv3 alert certificate unknown:state 23

Viktor Dukhovni

> On Apr 24, 2017, at 7:11 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
>
>    Please report tshark output, not an approximate rendition.  In what direction
>    is the alert sent?
>
> I’m using WireShark. The IP addresses on the Alert packet show local host as the source, and the proxy as the destination. Is there another way to tell the direction? Or how to present it in a way that I can sanitize the output and post here?

I get slightly annoyed when I take the time to help, but my response is
skimmed over and not read carefully.  Upthread I said:

See my recent post: https://www.spinics.net/lists/openssl-users/msg05623.html
for instructions on how to extract SSL info from PCAP files in a way that
mostly trims away endpoint details... (of course SNI names and cert names
would still be there, so you'd need to trim those if you want to anonymize
the guilty parties).

Install tshark somewhere, and use it to decode the PCAP file.  Then post
the results.

If the alert is from the application to the proxy, then most likely the
application does not trust the proxy MiTM root CA.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: What does this error mean? sslv3 alert certificate unknown:state 23

Blumenthal, Uri - 0553 - MITLL
On 4/24/17, 7:26 PM, "openssl-users on behalf of Viktor Dukhovni" <[hidden email] on behalf of [hidden email]> wrote:

    I get slightly annoyed when I take the time to help, but my response is
    skimmed over and not read carefully.  Upthread I said:
   
    See my recent post: https://www.spinics.net/lists/openssl-users/msg05623.html
    for instructions on how to extract SSL info from PCAP files in a way that
    mostly trims away endpoint details...

My apologies. Please find attached the tshark-processed (as instructed) PCAPNG file. I’d love to learn what one can glean from it.


    If the alert is from the application to the proxy, then most likely the
    application does not trust the proxy MiTM root CA.
   
Thanks!  


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

visual-para4.txt (30K) Download Attachment
smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What does this error mean? sslv3 alert certificate unknown:state 23

Viktor Dukhovni

> On Apr 25, 2017, at 3:17 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:

> Secure Sockets Layer
>     SSL Record Layer: Handshake Protocol: Client Hello
>         Content Type: Handshake (22)
>         Version: TLS 1.2 (0x0303)
>         Length: 228
>         Handshake Protocol: Client Hello
>             Handshake Type: Client Hello (1)
>             Length: 224
>             Version: TLS 1.2 (0x0303)
> ... vanilla client hello ...
>
> Secure Sockets Layer
>     TLSv1.2 Record Layer: Handshake Protocol: Server Hello
>         Content Type: Handshake (22)
>         Version: TLS 1.2 (0x0303)
>         Length: 89
>         Handshake Protocol: Server Hello
>             Handshake Type: Server Hello (2)
>             Length: 85
>             Version: TLS 1.2 (0x0303)
>             Random
>                 GMT Unix Time: Jan 12, 2043 21:01:43.000000000 EST
>                 Random Bytes: 74befd6060b40803a1f2eeee81de721667ea45ac751fb7cd...
>             Session ID Length: 32
>             Session ID: c07a259d71e9906c44632f6f9e885d40a647d514ef5deb8b...
>             Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
> ... vanilla server hello ...
>
> Secure Sockets Layer
>     TLSv1.2 Record Layer: Handshake Protocol: Certificate
>         Content Type: Handshake (22)
>         Version: TLS 1.2 (0x0303)
>         Length: 2017
>         Handshake Protocol: Certificate
>             Handshake Type: Certificate (11)
>             Length: 2013
>             Certificates Length: 2010
>             Certificates (2010 bytes)
>                 Certificate Length: 1038
>                 Certificate (id-at-commonName=cs.visual-paradigm.com)
>                     signedCertificate
>                         version: v3 (2)
>                         serialNumber : 0x1c3d07eea2d576e83c60613e5f3c2a18e518b8a0
>                         signature (sha256WithRSAEncryption)
>                             Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

EE cert sigalg is normal

>                         issuer: rdnSequence (0)
>                             rdnSequence: 6 items (id-at-commonName=McAfee Web Gateway,id-at-countryName=US,...
>                                 RDNSequence item: 1 item (id-at-organizationName=MIT Lincoln Laboratory)
>                                     RelativeDistinguishedName item (id-at-organizationName=MIT Lincoln Laboratory)
>                                         Id: 2.5.4.10 (id-at-organizationName)
>                                         DirectoryString: uTF8String (4)
>                                             uTF8String: MIT Lincoln Laboratory
>                                     . . . . .
>                                 RDNSequence item: 1 item (id-at-commonName=McAfee Web Gateway)
>                                     RelativeDistinguishedName item (id-at-commonName=McAfee Web Gateway)
>                                         Id: 2.5.4.3 (id-at-commonName)
>                                         DirectoryString: uTF8String (4)
>                                             uTF8String: McAfee Web Gateway

EE cert issuer looks OK.

>                         validity
>                             notBefore: utcTime (0)
>                                 utcTime: 17-04-24 18:35:25 (UTC)
>                             notAfter: utcTime (0)
>                                 utcTime: 18-04-24 18:35:25 (UTC)


EE cert validity is one year, looks OK.

>                         subject: rdnSequence (0)
>                             rdnSequence: 1 item (id-at-commonName=cs.visual-paradigm.com)
>                                 RDNSequence item: 1 item (id-at-commonName=cs.visual-paradigm.com)
>                                     RelativeDistinguishedName item (id-at-commonName=cs.visual-paradigm.com)
>                                         Id: 2.5.4.3 (id-at-commonName)
>                                         DirectoryString: uTF8String (4)
>                                             uTF8String: cs.visual-paradigm.com

EE cert Subject looks OK.

>                         subjectPublicKeyInfo
>                             algorithm (rsaEncryption)
>                                 Algorithm Id: 1.2.840.113549.1.1.1 (rsaEncryption)
>                             Padding: 0
>                             subjectPublicKey: 3082010a02820101009a686b8a742ec2e4341a6f43e20f71...

The EE public key is 256 octets or 2048 bits, looks OK.

>                         extensions: 5 items
>                             Extension (id-ce-basicConstraints)
>                                 Extension Id: 2.5.29.19 (id-ce-basicConstraints)
>                                 BasicConstraintsSyntax [0 length]

EE empty basicConstraints defaults to CA:FALSE, OK

>                             Extension (id-ce-subjectKeyIdentifier)
>                                 Extension Id: 2.5.29.14 (id-ce-subjectKeyIdentifier)
>                                 SubjectKeyIdentifier: 749037cb5eef9dc9b52ade1c2c465c61f1a63206

Not interesting for an EE cert.

>                             Extension (id-ce-authorityKeyIdentifier)
>                                 Extension Id: 2.5.29.35 (id-ce-authorityKeyIdentifier)
>                                 AuthorityKeyIdentifier
>                                     authorityCertIssuer: 1 item
>                                         GeneralName: directoryName (4)
>                                             directoryName: rdnSequence (0)
>                                                 rdnSequence: 6 items (id-at-commonName=McAfee Web Gateway,...
>                                                     RDNSequence item: 1 item (id-at-organizationName=MIT Lincoln Laboratory)
>                                                         RelativeDistinguishedName item (id-at-organizationName=MIT Lincoln Laboratory)
>                                                             Id: 2.5.4.10 (id-at-organizationName)
>                                                             DirectoryString: uTF8String (4)
>                                                                 uTF8String: MIT Lincoln Laboratory
>                                                             . . . . .
>                                                     RDNSequence item: 1 item (id-at-commonName=McAfee Web Gateway)
>                                                         RelativeDistinguishedName item (id-at-commonName=McAfee Web Gateway)
>                                                             Id: 2.5.4.3 (id-at-commonName)
>                                                             DirectoryString: uTF8String (4)
>                                                                 uTF8String: McAfee Web Gateway
>                                     authorityCertSerialNumber: 1

EE authority key id has DN and serial

>                             Extension (id-ce-keyUsage)
>                                 Extension Id: 2.5.29.15 (id-ce-keyUsage)
>                                 Padding: 5
>                                 KeyUsage: a0 (digitalSignature, keyEncipherment)
>                                     1... .... = digitalSignature: True
>                                     .0.. .... = contentCommitment: False
>                                     ..1. .... = keyEncipherment: True
>                                     ...0 .... = dataEncipherment: False
>                                     .... 0... = keyAgreement: False
>                                     .... .0.. = keyCertSign: False
>                                     .... ..0. = cRLSign: False
>                                     .... ...0 = encipherOnly: False
>                                     0... .... = decipherOnly: False

EE ku is OK.

>                             Extension (id-ce-extKeyUsage)
>                                 Extension Id: 2.5.29.37 (id-ce-extKeyUsage)
>                                 KeyPurposeIDs: 1 item
>                                     KeyPurposeId: 1.3.6.1.5.5.7.3.1 (id-kp-serverAuth)

EE eku is OK

>                     algorithmIdentifier (sha256WithRSAEncryption)
>                         Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption)
>                     Padding: 0
>                     encrypted: 76a83746f5faf96fe7911ad7fd57c7240262fcec5439075e...

EE cert fine overall.

>                 Certificate Length: 966
>                 Certificate (id-at-commonName=McAfee Web Gateway,. . .
>                     signedCertificate
>                         version: v3 (2)
>                         serialNumber: 1

Issuer serial matches EE cert issuer and authority key id.

>                         signature (shaWithRSAEncryption)
>                             Algorithm Id: 1.2.840.113549.1.1.5 (shaWithRSAEncryption)

Self-signature is SHA1, but should be OK on root CA certs.

>                         issuer: rdnSequence (0)
>                             rdnSequence: 6 items (id-at-commonName=McAfee Web Gateway,...
>                                 RDNSequence item: 1 item (id-at-organizationName=MIT Lincoln Laboratory)
>                                     RelativeDistinguishedName item (id-at-organizationName=MIT Lincoln Laboratory)
>                                         Id: 2.5.4.10 (id-at-organizationName)
>                                         DirectoryString: uTF8String (4)
>                                             uTF8String: MIT Lincoln Laboratory
>                                         . . . . .
>                                 RDNSequence item: 1 item (id-at-commonName=McAfee Web Gateway)
>                                     RelativeDistinguishedName item (id-at-commonName=McAfee Web Gateway)
>                                         Id: 2.5.4.3 (id-at-commonName)
>                                         DirectoryString: uTF8String (4)
>                                             uTF8String: McAfee Web Gateway

Issuer is self-signed, see below

>                         validity
>                             notBefore: utcTime (0)
>                                 utcTime: 12-08-07 21:51:05 (UTC)
>                             notAfter: utcTime (0)
>                                 utcTime: 22-08-07 21:51:05 (UTC)

Issuer 10 year validity is fine.

>                         subject: rdnSequence (0)
>                             rdnSequence: 6 items (id-at-commonName=McAfee Web Gateway,. . .
>                                 RDNSequence item: 1 item (id-at-organizationName=MIT Lincoln Laboratory)
>                                     RelativeDistinguishedName item (id-at-organizationName=MIT Lincoln Laboratory)
>                                         Id: 2.5.4.10 (id-at-organizationName)
>                                         DirectoryString: uTF8String (4)
>                                             uTF8String: MIT Lincoln Laboratory
>                                         . . . . .
>                                 RDNSequence item: 1 item (id-at-commonName=McAfee Web Gateway)
>                                     RelativeDistinguishedName item (id-at-commonName=McAfee Web Gateway)
>                                         Id: 2.5.4.3 (id-at-commonName)
>                                         DirectoryString: uTF8String (4)
>                                             uTF8String: McAfee Web Gateway

Same subject/issuer and issuer subject name matches EE cert issuer name, ...

>                         subjectPublicKeyInfo
>                             algorithm (rsaEncryption)
>                                 Algorithm Id: 1.2.840.113549.1.1.1 (rsaEncryption)
>                             Padding: 0
>                             subjectPublicKey: 3082010a028201010085b3b7c94a1150fdde952428b6a343...

Issuer cert also 2048-bits.

>                         extensions: 4 items
>                             Extension (ns_cert_exts.comment)
>                                 Extension Id: 2.16.840.1.113730.1.13 (ns_cert_exts.comment)
>                                 BER Error: String with tag=22 expected but class:UNIVERSAL(0) primitive tag:12 was unexpected
>                                     [Expert Info (Warn/Malformed): BER Error: String expected]
>                                         [BER Error: String expected]
>                                         [Severity level: Warn]
>                                         [Group: Malformed]

This is odd, is tshark buggy, too picky, or is the issuer cert actually malformed?

>                             Extension (id-ce-subjectAltName)
>                                 Extension Id: 2.5.29.17 (id-ce-subjectAltName)
>                                 GeneralNames: 1 item
>                                     GeneralName: rfc822Name (1)
>                                         rfc822Name: [hidden email]
>                             Extension (id-ce-basicConstraints)
>                                 Extension Id: 2.5.29.19 (id-ce-basicConstraints)
>                                 BasicConstraintsSyntax
>                                     cA: True

Good, issuer is a CA

>                             Extension (id-ce-keyUsage)
>                                 Extension Id: 2.5.29.15 (id-ce-keyUsage)
>                                 Padding: 1
>                                 KeyUsage: 06 (keyCertSign, cRLSign)
>                                     0... .... = digitalSignature: False
>                                     .0.. .... = contentCommitment: False
>                                     ..0. .... = keyEncipherment: False
>                                     ...0 .... = dataEncipherment: False
>                                     .... 0... = keyAgreement: False
>                                     .... .1.. = keyCertSign: True
>                                     .... ..1. = cRLSign: True
>                                     .... ...0 = encipherOnly: False
>                                     0... .... = decipherOnly: False

Issuer ku is OK

>                     algorithmIdentifier (shaWithRSAEncryption)
>                         Algorithm Id: 1.2.840.113549.1.1.5 (shaWithRSAEncryption)
>                     Padding: 0
>                     encrypted: 408fc9a991e6cebbec05fa6b2463d89bcb8b2dc888c1a1b6...

Issuer cert is an MiTM proxy, and possibly has encoding errors.

> Secure Sockets Layer
>     TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
>         Content Type: Handshake (22)
>         Version: TLS 1.2 (0x0303)
>         Length: 333
>         Handshake Protocol: Server Key Exchange
>             Handshake Type: Server Key Exchange (12)
>             Length: 329
>             EC Diffie-Hellman Server Params

ECDHE, no problem.

>     TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done

Fine, no request for client cert.

> Secure Sockets Layer
>     TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Certificate Unknown)
>         Content Type: Alert (21)
>         Version: TLS 1.2 (0x0303)
>         Length: 2
>         Alert Message
>             Level: Fatal (2)
>             Description: Certificate Unknown (46)

Client objects to the server chain.  Either does not trust the MiTM root CA, or
is unhappy about its encoding (assuming tshark is not generating an FP warning).

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: What does this error mean? sslv3 alert certificate unknown:state 23

Blumenthal, Uri - 0553 - MITLL
    >                         extensions: 4 items
    >                             Extension (ns_cert_exts.comment)
    >                                 Extension Id: 2.16.840.1.113730.1.13 (ns_cert_exts.comment)
    >                                 BER Error: String with tag=22 expected but class:UNIVERSAL(0)
    >                                                               primitive tag:12 was unexpected
    >                                     [Expert Info (Warn/Malformed): BER Error: String expected]
    >                                         [BER Error: String expected]
    >                                         [Severity level: Warn]
    >                                         [Group: Malformed]
   
    This is odd, is tshark buggy, too picky, or is the issuer cert actually malformed?

I don’t know off-hand, will check, and bring to the attention of those who run the proxy.

   
    >                     algorithmIdentifier (shaWithRSAEncryption)
    >                         Algorithm Id: 1.2.840.113549.1.1.5 (shaWithRSAEncryption)
    >                     Padding: 0
    >                     encrypted: 408fc9a991e6cebbec05fa6b2463d89bcb8b2dc888c1a1b6...
   
    Issuer cert is an MiTM proxy, and possibly has encoding errors.
   
Got it, thanks.



    > Secure Sockets Layer
    >     TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Certificate Unknown)
    >         Content Type: Alert (21)
    >         Version: TLS 1.2 (0x0303)
    >         Length: 2
    >         Alert Message
    >             Level: Fatal (2)
    >             Description: Certificate Unknown (46)
   
    Client objects to the server chain.  Either does not trust the MiTM root CA, or
    is unhappy about its encoding (assuming tshark is not generating an FP warning).
   
Thank you!  So it is the *client* that breaks the connection, and it is unhappy either about MiTM, or the encoding. I will check for both (though not much I can do about either).

Thanks! (At least I have an idea now what’s going on.)

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: What does this error mean? sslv3 alert certificate unknown:state 23

Viktor Dukhovni

> On Apr 25, 2017, at 4:41 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:
>
>    Client objects to the server chain.  Either does not trust the MiTM root CA, or
>    is unhappy about its encoding (assuming tshark is not generating an FP warning).
>
> Thank you!  So it is the *client* that breaks the connection, and it is unhappy either about MiTM, or the encoding. I will check for both (though not much I can do about either).

Well, if there is not facility to configure the client's trusted root CAs,
then of course it won't trust the MiTM root cert.  Presumably you've added
that cert to some trust store on the system in question.

The support staff for the product should be able to tell you how to configure
trusted TLS CAs, if these are configurable.

If the product is not using OpenSSL, this question really is off topic for
this list.  If it is using OpenSSL, there may be some place where it looks
for its CAfile or some CApath directory.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: What does this error mean? sslv3 alert certificate unknown:state 23

Blumenthal, Uri - 0553 - MITLL
      > Thank you!  So it is the *client* that breaks the connection,
      > and it is unhappy either about MiTM, or the encoding. I will
      > check for both (though not much I can do about either).
   
  Presumably you've added that cert to some trust store on the system in question.

Yes I did (though reluctantly :).
   
    The support staff for the product should be able to tell you how to configure
    trusted TLS CAs, if these are configurable.

Yes, I’m bringing this to them, in hope that they’d resolve it.
   
    If the product is not using OpenSSL, this question really is off topic for
    this list.  If it is using OpenSSL, there may be some place where it looks
    for its CAfile or some CApath directory.

Frankly, I don’t know – to me it’s an executable black-box. I’ll try to dig. But I think you’ve provided me with all I need to point our support at the root cause.

Thanks!!

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (6K) Download Attachment