I have encountered a server which presents an invalid set of
certificates in its TLS handshake.
It's presenting four certificates, where the second cert is *not* the
issuer of the first cert in the list. The chain from #2-#3-#4 is fine,
but #2 isn't actually the issuer of #1. (It just happens to
David,
Failing when a server sends the certificates out of order would result in a
large % of transactions failing. On platforms other than Windows the order is
determined by the server administrator and what order they put them in the
configuration.
I recommend not changing the behavior
Le 12/07/2012 15:36, David Woodhouse a écrit :
I have encountered a server which presents an invalid set of
certificates in its TLS handshake.
This is common. Really common.
It's presenting four certificates, where the second cert is *not* the
issuer of the first cert in the list. The chain
On 07/09/2012 03:55 PM, John Foley wrote:
According to the NIST web site, the 2.0 FIPS Object Module claims
compliance for FIPS 186-3 using the Extra Random Bits method for EC
public key generation.
The implementation is FIPS 186-3 Section B.4.2, Key Pair Generation by
Testing Candidates. The
OK, thanks for clarifying this.
On 07/12/2012 02:53 PM, Steve Marquess wrote:
On 07/09/2012 03:55 PM, John Foley wrote:
According to the NIST web site, the 2.0 FIPS Object Module claims
compliance for FIPS 186-3 using the Extra Random Bits method for EC
public key generation.
The
If the actual issuing CA is in your trust store and can be shown to have
validly issued the server certificate, then by definition you trust that server.
Erik Tkal
Juniper OAC/UAC/Pulse Development
-Original Message-
From:
On Thu, 2012-07-12 at 20:44 +0200, Erwann Abalea wrote:
Le 12/07/2012 15:36, David Woodhouse a écrit :
I have encountered a server which presents an invalid set of
certificates in its TLS handshake.
This is common. Really common.
It's presenting four certificates, where the second cert
On 07/12/2012 10:00 PM, David Woodhouse wrote:
If it has the same name, then it's the same CA. Has it been rekeyed?
It has a different X509v3 Subject Key Identifier.
The Subject Key Identifier of the second cert in the list does not match
the Authority Key Identifier of the first cert. It's a
