The makings of PKCS12 

Keys and certificates are used to secure data by using the public key to encrypt and the private key to decrypt. A certificate is used as a stamp of authority. It can include the public key. 

Keys and certificates are often exchanged in PEM encoding. It is a format for a container that seems to have originated from Privacy Enhanced Mail which has long been abandoned. The container format proved useful. Keys and certificates in PEM encoding are easy to recognize with their distinctive BEGIN and END literals. 

PKCS12 is a more recent container format and one that can store one or more cryptography artifacts in what are called bags. It is made available in the form of a file with pfx extension or p12 extension. Although it can store keys, certificates, root and chains or any combinations of these, it is typically understood as a type of keystore which is a format widely accepted by applications written in Java to denote a combination of a  key and certificate. Together, this keystore can secure mutual authentication. We will go into mutual authentication a little later but first let us discuss this format a little bit more. It has been surprisingly fragile unless the packing and unpacking are done by the same tool which goes by the name keytool.  Usually, the keytool creates the keystore and the openssl tool unpacks or verifies it. 

A keystore also has an older and perhaps now deprecated format. We don’t need to go over that since the pkcs12 is more recent. By that same reasoning, it is yet to infuse into the libraries and sdks in all languages for applications that generally don’t want the inconvenience of knowing anything beyond a key and a certificate. 

PKCS12 format is a representation of an authenticated safe with one or more safe bags. There are many types of safe bag: some are used to store keys transparently, others are used as bags to shroud keys, some store certificates, others store certificate revocation lists and generally bags that can store any miscellaneous or future extensions. The format itself was meant as a simple collection of bags but unlike archive formats, there is no inbuilt verification to the count, size and consistency of bags or their contents. This makes handling very complicated at times involving nested switch case. OpenSSL also does a poor job of making all fields as optional which often breaks when fields don’t align or tags are not recognized and bags or contents cannot be skipped often resulting in errors like: 

"error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag  

error:0D07803A: asn1 encoding routines: ASN1_ITEM_EX_D2I: nested asn1 error"  

We mentioned mutual authentication earlier. It is a method where the server and the client present different certificates. In this sequence of message exchanges for mutual authentication between the server and the client, the server initiates the messages. First, the server sends hello message.  Next it sends the certificate, followed by a request to get the client’s certificate and lastly the server-side hello done message. The client responds first with its certificate. Then it sends the session key with the client key exchange message. Then it sends the certificate verify message and changes the cipher spec. Lastly it sends the client-side finished message. The server closes the mutual authentication with the cipher changed message and the server-side finished message.