JKS (Java Key Store) and PKCS12

  • What is a pem file

What is JKS?

  • A Java keystore stores private key entries, certificates with public keys or just secret keys that we may use for various cryptographic purposes.
  • It stores each by an alias for ease of lookup.
  • Generally speaking, keystores hold keys that our application owns that we can use to prove the integrity of a message and the authenticity of the sender, say by signing payloads.
  • Usually, we’ll use a keystore when we are a server and want to use HTTPS. During an SSL handshake, the server looks up the private key from the keystore and presents its corresponding public key and certificate to the client.
  • Correspondingly, if the client also needs to authenticate itself – a situation called mutual authentication – then the client also has a keystore and also presents its public key and certificate.
  • There’s no default keystore, so if we want to use an encrypted channel, we’ll have to set javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword. If our keystore format is different than the default, we could use javax.net.ssl.keyStoreType to customize it.
  • Of course, we can use these keys to service other needs as well. Private keys can sign or decrypt data, and public keys can verify or encrypt data. Secret keys can perform these functions as well. A keystore is a place that we can hold onto these keys.

Note :

  • Since Java 9, though, the default keystore format is PKCS12.
  • The biggest difference between JKS and PKCS12 is that JKS is a format specific to Java, while PKCS12 is a standardized and language-neutral way of storing encrypted private keys and certificates.

Java TrustStore (CACERT)

  • A truststore is the opposite – while a keystore typically holds onto certificates that identify us, a truststore holds onto certificates that identify others.
  • In Java, we use it to trust the third party we’re about to communicate with.
  • Take our earlier example. If a client talks to a Java-based server over HTTPS, the server will look up the associated key from its keystore and present the public key and certificate to the client.
  • We, the client, then look up the associated certificate in our truststore. If the certificate or Certificate Authorities (CA) presented by the external server is not in our truststore, we’ll get an SSLHandshakeException and the connection won’t be set up successfully.
  • Java has bundled a truststore called cacerts and it resides in the $JAVA_HOME/jre/lib/security directory.
    and it contains default, trusted Certificate Authorities:
keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts

Example : In the above system there are 134 keystore i.e 134 trusted CA and one of them is of affirmtrust_premium_ecc

If you go to their website you can see that they give permit to create SSL certificates for websites and they are considered as one of the CA by SUN

https://www.affirmtrust.com/

Here, we can override the default truststore location via the javax.net.ssl.trustStore property. Similarly, we can set javax.net.ssl.trustStorePassword and javax.net.ssl.trustStoreType to specify the truststore’s password and type.

What is java Keytool ?

  • Java Keytool is a key and certificate management utility. It allows users to manage their own public/private key pairs and certificates. It also allows users to cache certificates.
  • Java Keytool stores the keys and certificates in what is called a keystore.
  •  By default the Java keystore is implemented as a file. It protects private keys with a password.
  • A Keytool keystore contains the private key and any certificates necessary to complete a chain of trust and establish the trustworthiness of the primary certificate.
  • Java Keytool also several other functions that allow you to view the details of a certificate or list the certificates contained in a keystore or export a certificate.

Some standard formats and their explainations :

1750

SSL has been around for long enough you’d think that there would be agreed upon container formats. And you’re right, there are. Too many standards as it happens. So this is what I know, and I’m sure others will chime in.

  • .csr – This is a Certificate Signing Request. Some applications can generate these for submission to certificate-authorities. The actual format is PKCS10 which is defined in RFC 2986. It includes some/all of the key details of the requested certificate such as subject, organization, state, whatnot, as well as the public key of the certificate to get signed. These get signed by the CA and a certificate is returned. The returned certificate is the public certificate (which includes the public key but not the private key), which itself can be in a couple of formats.
  • .pem – Defined in RFCs 1421 through 1424, this is a container format that may include just the public certificate (such as with Apache installs, and CA certificate files /etc/ssl/certs), or may include an entire certificate chain including public key, private key, and root certificates. Confusingly, it may also encode a CSR (e.g. as used here) as the PKCS10 format can be translated into PEM. The name is from Privacy Enhanced Mail (PEM), a failed method for secure email but the container format it used lives on, and is a base64 translation of the x509 ASN.1 keys.
  • .key – This is a PEM formatted file containing just the private-key of a specific certificate and is merely a conventional name and not a standardized one. In Apache installs, this frequently resides in /etc/ssl/private. The rights on these files are very important, and some programs will refuse to load these certificates if they are set wrong.
  • .pkcs12 .pfx .p12 – Originally defined by RSA in the Public-Key Cryptography Standards (abbreviated PKCS), the “12” variant was originally enhanced by Microsoft, and later submitted as RFC 7292. This is a passworded container format that contains both public and private certificate pairs. Unlike .pem files, this container is fully encrypted. Openssl can turn this into a .pem file with both public and private keys: openssl pkcs12 -in file-to-convert.p12 -out converted-file.pem -nodes

A few other formats that show up from time to time:

  • .der – A way to encode ASN.1 syntax in binary, a .pem file is just a Base64 encoded .der file. OpenSSL can convert these to .pem (openssl x509 -inform der -in to-convert.der -out converted.pem). Windows sees these as Certificate files. By default, Windows will export certificates as .DER formatted files with a different extension. Like…
  • .cert .cer .crt – A .pem (or rarely .der) formatted file with a different extension, one that is recognized by Windows Explorer as a certificate, which .pem is not.
  • .p7b .keystore – Defined in RFC 2315 as PKCS number 7, this is a format used by Windows for certificate interchange. Java understands these natively, and often uses .keystore as an extension instead. Unlike .pem style certificates, this format has a defined way to include certification-path certificates.
  • .crl – A certificate revocation list. Certificate Authorities produce these as a way to de-authorize certificates before expiration. You can sometimes download them from CA websites.

In summary, there are four different ways to present certificates and their components:

  • PEM – Governed by RFCs, its used preferentially by open-source software. It can have a variety of extensions (.pem, .key, .cer, .cert, more)
  • PKCS7 – An open standard used by Java and supported by Windows. Does not contain private key material.
  • PKCS12 – A Microsoft private standard that was later defined in an RFC that provides enhanced security versus the plain-text PEM format. This can contain private key material. Its used preferentially by Windows systems, and can be freely converted to PEM format through use of openssl.
  • DER – The parent format of PEM. It’s useful to think of it as a binary version of the base64-encoded PEM file. Not routinely used very much outside of Windows.

Why JKS?

  • The purpose of a key store is to protect the privacy and integrity of cryptographic keys using password-based algorithms.
  • Privacy means that the keys are kept secret; they can only be used by someone who knows the password; this is useful for private keys and secret keys.
  • Integrity means that alteration of the keys can be detected by someone who knows the password; this is useful for public keys and secret keys.

Should JKS have public key or private key?

  • Whether you should include the private key or not depends on what you are trying to do.
  • If you are creating a key store for your server so that it can authenticate itself to clients, for example, then it should contain the private key. 
  • If you created a self-signed certificate, and want to give clients a key store so that they can authenticate your service, then it should not contain the private key.

Creating or placing a key pair under JKS ?

Verification of JKS ?

  • You should verify the integrity of a public key or a certificate before you use it to encrypt a message or verify a signature. Because, an attacker can replace the key with one he owns and act as a man in the middle.
  • If you simply read a public key from a file, you don’t know it really belongs to your intended recipient. But if you store a password-based message authentication code with the public key, you can ensure that it hasn’t been tampered with.

Lets do the basics :

HTTP is a protocol which transfers data in unencrypted format over the internet which is not secure hence we use HTTPS, now to implement HTTPS we need SSL/TLS implementation

https://www.youtube.com/watch?v=T4Df5_cojAs

What is SSL ?

  • The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) is the most widely deployed security protocol used today. It is essentially a protocol that provides a secure channel between two machines operating over the Internet or an internal network. 
  • In today’s Internet focused world, the SSL protocol is typically used when a web browser needs to securely connect to a web server over the inherently insecure Internet.

Now as we know now to communicate securely over internet we need SSL/TLS, how to we achieve what ?

  • We achieve by using certificates and encryptions
  • Lets see the steps required to add an SSL (to a website)
  •  First up are certificate signing requests (CSRs). 
  • These little files are a critical part of applying for an SSL Certificate, but what are they exactly and how can you generate one?
  • A certificate signing request (CSR) is one of the first steps towards getting your own SSL Certificate. 
  • Generated on the same server you plan to install the certificate on, the CSR contains information (e.g. common name, organization, country) the Certificate Authority (CA) will use to create your certificate.
  •  It also contains the public key that will be included in your certificate and is signed with the corresponding private key. 
  • Below are the contents of CSR
    • Information about bussiness
      • Common Name (CN) = www.example.com
      • Organization (O) = The legal name of your organization
      • Organizational Unit (OU) = The division of your organization handling the certificate.
      • City/Locality (L) = The city where your organization is located. 
      • State/County/Region (S) = The state/region where your organization is located.
      • Country (C) = The two-letter code for the country
      • Email Address = An email address used to contact your organization.
    • Public Key
      • The public key that will be included in the certificate. SSL uses public-key, or asymmetric, cryptography to encrypt transmitted data during an SSL session.
      • The public key is used to encrypt and the corresponding private key is used to decrypt.
    • Information about key type and length
      • The most common key size is RSA 2048, but some CAs support larger key sizes (e.g. RSA 4096+) or ECC keys.

What does a CSR look like :

  • The CSR itself is usually created in a Base-64 based PEM format.
  • You can open the CSR file using a simple text editor and it will look like the sample below.
  • You must include the header and footer (—–BEGIN NEW CERTIFICATE REQUEST—–) when pasting the CSR.

Example CSR :

-----BEGIN NEW CERTIFICATE REQUEST-----MIIDVDCCAr0CAQAweTEeMBwGA1UEAxMVd3d3Lmpvc2VwaGNoYXBtYW4uY29tMQ8w DQYDVQQLEwZEZXNpZ24xFjAUBgNVBAoTDUpvc2VwaENoYXBtYW4xEjAQBgNVBAcT CU1haWRzdG9uZTENMAsGA1UECBMES2VudDELMAkGA1UEBhMCR0IwgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAOEFDpnOKRabQhDa5asDxYPnG0c/neW18e8apjOk 1yuGRk+3GD7YQvuhBVS1x6wkw1D2RnmnZgN1nNUK0cRK7sIvOyCh1+jgD7u46mLk 81j+b4YSEmYZGPLIuclyocPDm0hXayjCUqWt7z6LMIKpLym8gayEZzz9Gn97PsbP kVFBAgMBAAGgggGZMBoGCisGAQQBgjcNAgMxDBYKNS4xLjI2MDAuMjB7BgorBgEE AYI3AgEOMW0wazAOBgNVHQ8BAf8EBAMCBPAwRAYJKoZIhvcNAQkPBDcwNTAOBggq hkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMH MBMGA1UdJQQMMAoGCCsGAQUFBwMBMIH9BgorBgEEAYI3DQICMYHuMIHrAgEBHloA TQBpAGMAcgBvAHMAbwBmAHQAIABSAFMAQQAgAFMAQwBoAGEAbgBuAGUAbAAgAEMA cgB5AHAAdABvAGcAcgBhAHAAaABpAGMAIABQAHIAbwB2AGkAZABlAHIDgYkAk0kf HSkr4jsEVya3mgUoyaYMO456ECNZr4Cb+WhPgexfjOO5qwOG1oDOTaKycrkc5pG+ IPBQnq+4cotT8hWJQwpc+qGb8xUETpxCokhrhN5079vFXq/5dsHkmtOTwkSqSnz9 yruVoxYeDQ8jI3KG3HTgxwFto8oZnm+E+Y4oshUAAAAAAAAAADANBgkqhkiG9w0B AQUFAAOBgQAuAxetLzgfjBdWpjpixeVYZXuPZ+6jvZNL/9hOw7Fk5pVVXWdr8csJ 6JUW8QdH9KB6ZlM4yg8Df+vat1/DG6GuD2hiIR7fQ0NtPFBQmbrSm+TTBo95lwP+ ZSZTusPFTLKaqValdnS9Uw+6Vq7/I4ouDA8QBIuaTFtPOp+8wEGBHQ==
-----END NEW CERTIFICATE REQUEST-----

How do you generate your own CSR :

  • Generating the CSR will depend on the platform you’re using. 
  • We have a number of support articles with step-by-step insturctions for doing this in the most popular platforms, including cPanel, Exchange, IIS, Java Keytool and OpenSSL.

Java Keytool Common Commands :

Generate a Java keystore and key pair

keytool -genkey -alias mydomain -keyalg RSA -keystore keystore.jks  -keysize 2048

Generate a certificate signing request (CSR) for an existing Java keystore

keytool -certreq -alias mydomain -keystore keystore.jks -file mydomain.csr

Import a root or intermediate CA certificate to an existing Java keystore

keytool -import -trustcacerts -alias root -file Thawte.crt -keystore keystore.jks

Import a signed primary certificate to an existing Java keystore

keytool -import -trustcacerts -alias mydomain -file mydomain.crt -keystore keystore.jks

Generate a keystore and self-signed certificate

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048

Java Keytool Commands for checking

Check a stand-alone certificate

keytool -printcert -v -file mydomain.crt

Check which certificates are in a Java keystore

keytool -list -v -keystore keystore.jks

Check a particular keystore entry using an alias

keytool -list -v -keystore keystore.jks -alias mydomain

Other Java Keytool Commands

Delete a certificate from a Java Keytool keystore

keytool -delete -alias mydomain -keystore keystore.jks

Change a Java keystore password

keytool -storepasswd -new new_storepass -keystore keystore.jks

Export a certificate from a keystore

keytool -export -alias mydomain -file mydomain.crt -keystore keystore.jks

List Trusted CA Certs

keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacerts

Import New CA into Trusted Certs

keytool -import -trustcacerts -file /path/to/ca/ca.pem -alias CA_ALIAS -keystore $JAVA_HOME/jre/lib/security/cacerts

Read Me :

https://docs.oracle.com/cd/E19830-01/819-4712/ablqw/index.html
https://serverfault.com/questions/9708/what-is-a-pem-file-and-how-does-it-differ-from-other-openssl-generated-key-file

Leave a Comment