On 5/1/2013 6:46 PM, Salz, Rich wrote:
It should not be surprising that both keypairs worked. Unless you’re
doing mutual authentication, the SSL server will never see the client
certificate, and so it will not be able to see the keyUsage attribute,
or the extendedKeyUsage attribute. Those two attributes specify how a
keypair is “supposed” to be used. If you’re very very picky, you want
keyUsage to have digitialSignature and keyEncipherment turned on, and
extendedKeyUsage to include serverAuth or clientAuth. If you’re not
very picky, use your signing keypair, not your encryption keypair.
I believe the OP describes the situation where two near-identical
certificates are issued simultaneously to the same entity, with the
same DN, but with different public keys and different keyUsage
attributes. This is sometimes supplemented by a hardware engine
(such as a smartcard or USB key) that prevents performing the wrong
PKCS#1 operation with each key. For instance the once ubiquitous
Aladdin eToken did that by default when using the standard firmware and
drivers. This concept is also deeply engrained in Microsofts CryptoAPI
(the old one, not the new Vista API) and in the old (pre-2000) US export
regulations.
When used for e-mail one cert will be used for signing (and private key
loss is preferable to a backup key being misused), while the other will
be used for encryption (and key backup is recommended in order to
preserve access to previously encrypted mails). Signed e-mails will
typically provide *both* certificates in the PKCS#7 certificate
collection and clients running at the recipient are supposed to cache
both certificates and use the keyUsage attributes to pick the right
certificate when sending back an encrypted mail.
When such a certificate pair is used for SSL/TLS client auth, it is
recommended to use the digitalSignature certificate and key, since that
is the cryptographic operation performed and the one with the proper
tradeoff of key loss versus key misuse for authentication purposes.
Using such a certificate pair for SSL/TLS server auth is not meaningful,
as only one kind of certificate should be used by and issued to the
server, this one with keyEncipherment and digitalSignature both enabled
(digitalSignature is used for cipher choices that use a temporary public
key for the actual key exchange and the public key from the certificate
to authenticate that key). However the server key should not have key
backup as there are no stored encrypted data that needs to be decrypted.
For a bit more info on the attributes, see the x509v3_config manpage
(http://www.openssl.org/docs/apps/x509v3_config.html#Extended_Key_Usage_) and/or
google it.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
