2
$\begingroup$

We have proprietary tool which takes a p12 file and generates a .key file. Inside the key file, I see two PEM formatted sections: Encrypting Certificate and Signing Certificate. When I open them on my machine they have the same CN, Expiration and Issuer, etc. This key file is used for mutual 2-way authentication and we provide the key file to the client.

What is happening here? I understand the regular mutual authentication where you and client exchange public keys and trust them but why do you need to implement this method?

$\endgroup$
  • $\begingroup$ What is exactly your question? Could it be "why are there two certificates with the same user data but different purpose"? $\endgroup$ – Sergio Andrés Figueroa Santos Mar 10 '16 at 13:35
  • $\begingroup$ Exactly and how is this method different from regular 2-way authentication, where you exchange certificate(plus the chain) with a client. $\endgroup$ – ObiWanKenobi Mar 10 '16 at 13:41
0
$\begingroup$

It is usually regarded as a bad practice to use the same key for encryption and signatures, which means that one node (user, server, etc.) will have two keypairs: one to be used to sign content (the public key is used to verify) and one to decrypt content (the public key is used to encrypt). As a result, if you want fully authenticated and encrypted communication for two parties in this scenario, you will need 4 key pairs (two on each side of the communication).

Exporting the keys into .key files might be necessary in some scenarios due to compatibility, but it takes away the properties of a certificate and its legal binding power (since the key could be tampered without any straightforward way to notice).

After reading your comment, I'd focus on the point of each of the certificates. For that, suppose that you're the client of a bank. From your point of view, you might be interested in achieving authentication+integrity/confidentiality or both. For instance:

  • You get into their webpage to get the name of the phone number: you need to know that the number is right and belongs to them, and so it makes sense to expect the validate a signature associated with the webpage, so you don't get scammed. A server signature is needed

  • You send the bank an anonymous complaint: you only need to encrypt the message with the public key of the bank. An encryption to the server is needed

  • You want to login into your online banking and check information: you need to make sure that the information comes from the bank (signed) and that the information you send is only read by the bank (encrypted). You need both tasks.

Note that, at this point, no certificate or personal information has been given about you, as a client. You can use your own pair of certificates (in practice aided by a smart card, for instance), or, as in most cases, a weaker authentication method (password, password+one time password, etc.). In the latter case, a trusted session could be created with the mediation of only two certificates, both on the server side.

So, as you see, you can define schemes with 1, 2, 3 or 4 certificates, depending on the specific requirements and the availability of additional security controls. However, between servers the case with 4 certificates seems to be the more reasonable.

$\endgroup$
  • $\begingroup$ Hi Sergio, thanks for the explanation. The other method I am talking about is Mutual Authentication sometimes called as 2-Way Authentication. AFIK, You use only one public key and exchange with client and perform the SSL communication. So wanted to know why are we using encryption/signing certificates when you can accomplish with one certificate. $\endgroup$ – ObiWanKenobi Mar 10 '16 at 15:18
  • $\begingroup$ Hi Sergio, thanks for the explanation. The other method I am talking about is Mutual Authentication sometimes called as 2-Way Authentication. AFIK, You use only one public key and exchange with client and perform the SSL communication. So wanted to know why are we using encryption/signing certificates when you can accomplish with one certificate. $\endgroup$ – ObiWanKenobi Mar 10 '16 at 15:19
0
$\begingroup$

The PKCS12 (p12, pfx) is a standardized keystore where you may store multiple keypairs (key and certificate) or certificates themselves. It can be read/manipulted by multiple tools (OpenSSL, Keytool, keytool-explorer, ...).

You may have multiple certificates in you PKCS12 archive, it's usually a certificate chain with the certificate itself and its issuer (certificate authority). The certificates should be 'chained' (in a hierarchy).

Mutual SSL is used where the trust needs to be mutual (it's not only you want to be sure you speak to the right server (server only SSL), the server wants to be sure the client is who it claims to be). During the SSL handshake (or SSL renogotiation) the SSL server passes a set of trusted certificate authorities and the client then provides its own certificate if it is trusted by one of the offered CAs. Then the identity (private key ownership) is ensured by exchanging encrypted piece of data. It is a very effective method ensuring that only trusted clients are able to connect to the service.

Updated: why are there two certificates with the same user data but different purpose? You have 2 certificates to the same key? Do they have the same issuer? Technically any certificate could be used to authenticate or to sign data. Legally - it may be different. It is common (e.g. on the eID cards) to have separate certificate for authentication and for signing. So you don't sign anything (legally binding) while you think you are authenticating to a service.. But -if they are both in the same keystore - don't you have the certificate chain there?

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.