Most common openssl commands

This post is a collection of most common and helpful openssl commands which we need to use to deal with tasks like generating keys, CSRs, certificates.

# Verify or check content

Verify a certificate file

openssl x509 -in thecodersstop.pem -text -noout

Verify a CSR request

openssl req -text -noout -verify -in thecodersstop.csr

Verify a private key file

openssl rsa -in thecodersstop-key.key -check

Check contents of PKCS12 format cert (.pfx or p12)

openssl pkcs12 -info -nodes -in thecodersstop.pfx

Verify a certificate against a CA certificate

openssl verify -CAfile ca.pem thecodersstop.pem

# Create using openssl

Create a Self-Signed Certificate

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout thecodersstop-key.key -out thecodersstop.pem

Create private key and CSR (certificate signing request)

openssl req -out thecodersstop.csr -newkey rsa:2048 -nodes -keyout thecodersstop-key.key

Create RSA private key

openssl genrsa -out thecodersstop-key.key 2048

Generate a CSR using an existing private key

openssl req -out thecodersstop.csr -key thecodersstop-key.key -new

Create unecrypted key from a password protected private key

openssl rsa -in thecodersstop-key.key -out thecodersstop-key-unencrypted.pem -passin pass:1234

Remove passphrase from a private key

openssl rsa -in thecodersstop-key.key -out thecodersstop-key-new.key

# Convert using openssl

Convert pem certificate and private Key to PKCS#12 format (.pfx or p12)

openssl pkcs12 -export -out thecodersstop.pfx -inkey thecodersstop-key.key -in thecodersstop.pem

Convert PEM certificate to DER format

openssl x509 -outform der -in thecodersstop.pem -out thecodersstop.der

Please like and share if you found this post useful. If you need help with a command which is not there in the list, please let us know, we will help you and add it here also.

Any suggestions and feedback are welcome, please comment so that we can consider your valuable feedback. Thanks for reading!

Tagged : / / / /

How is data secure over https?

Everyone of us have heard that data transferred over HTTPS is secured. As a result we provide our highly confidential information like bank details, credit card details to a website which runs overHTTPS .

Have you ever thought what makes your data secure when transferred over HTTPS ? How HTTPS makes sure that the data cannot be read by any intruder ?

In this article I am going to explain what goes behind the scenes when you submit your confidential information on a browser.

First let’s understand what is SSL, TLS, HTTPS ?

SSL (Secure socket layer ) — is a technology used for keeping an internet connection secure for transmission of any sensitive information between two systems. The two systems can be a client(like a browser) and server (like a bank application).

TLS (Transport layer security) — is just an updated, more secure version of SSL. The algorithms used in TLS are more secure.

HTTPS (Hyper text transfer Protocol SECURE) — is a protocol used to transfer data which is secured by SSL/TLS. So simply HTTPS is HTTP + SSL/TLS .

Now let’s take an example to understand how SSL/TLS works ? Suppose you are ordering food on website . In order to pay, you enter confidential information like card details on payment page presented to you in browser. Once you click on submit, this information is sent to the bank server which verifies the card details and responds with some message like transaction success or failure .

In the above scenario our client is Browser and the server is Bank server . Let’s go through the steps involved in the complete scenario after you clicked on Submit button on browser.


Before any actual data exchange client sends a “client hello” message to the server indicating that I want to establish a secure connection. This message includes client information like SSL/TLS version, supported cipher-suites and supported data compression methods.

Client browsers may be old and not supporting latest version of SSL/TLS, modern cipher suites etc. So they send this information to server in “client hello” message.

A cipher-suite is a set of cryptographic algorithms which can be used to encrypt/decrypt data like DES, AES, 3DES etc.


In response to “client hello” server responds with a “server hello” message which contains server information like the chosen cipher-suite from the list provided by client and itsdigital certificate.

After the above two steps, both client and server agreed on a SSL/TLS version and a cryptographic algorithm from the cipher suite which will be used for encryption/decryption.

STEP3: Server authentication

The client verifies server’s digital certificate sent in STEP2 by checking if the provided certificate is expired or not, is it issued by a trusted certificate authority or not, does the domain name in certificate matches server’s domain name or not. If the answer to all these questions is YES server authentication is successful.

Each SSL enabled client maintains a list of trusted Certificate authorities(CAs). The list determines which server certificate the client accepts. If the issuing CA is not in the list of the pre-determined CA list, server is not authenticated unless the client can verify a certificate chain ending in a CA that is on the list.

STEP4: Secret key exchange

The client generates one random string and encrypts it with server’s public key. After that it sends the encrypted string to server. Since the string is encrypted by server’s public key, no one can decrypt it without server’s private key. This encrypted string is used by both server/client to compute a secret key which will be used to encrypt/decrypt data exchange between them.

Note here that after this step both client and server have a common secret key which can be used to encrypt/decrypt data. It is known as a Symmetric key .

STEP5: Client HELLO finished

The client sends server a finished message, which is encrypted with the secret key, indicating that the client part of handshake is complete.

STEP6: Server HELLO finished

The server sends client a finished message, which is again encrypted with the secret key, indicating that the server part of handshake is also complete.

STEP7: Data exchange

For the duration of session, client and server can now exchange data that is encrypted with shared secret key. Since only client and server have the secret key, no one can read the messages in between.

So after STEP6 is completed, the actual data exchange between server and client can take place.

As you may have observed that in STEP3 client verifies the server’s digital certificate to make sure the client is talking to a genuine server. SSL/TLS has one more very interesting thing in which a server can also ask a client to prove its identity. It is known as Mutual TLS.

For example, when you access your browser verifies google’s digital certificate. Google never asks you to prove your identity by presenting a certificate. Mutual TLS can prove to be a very secure way for authenticating clients. In my next post, I will write about how mutual TLS works.

Thanks for reading and hope you learned something new. Feel free to comment if you have any suggestions or corrections.

Tagged : / /

Secure way of doing OAuth for SPA & Native Apps

When clients like mobile, desktop, single page applications allows the user to sign-in using a third party application (google, facebook, twitter etc), one of the first choice is to use OAuth 2.0 standard with authorization code flow.

In Authorization code flow, authorization request is made via browser and an authorization code is returned to the redirect URL registered by the client. This authorization code is used by public clients to request for an access token to get access to resources.

Intercept Attack

Protecting this authorization code is thus critical but in most cases the public clients make use of custom URL scheme to capture redirects (e.g myapp://callback) thus having the risk of malicious applications to receive the authorization code.

Malicious apps can register the same custom URL scheme (myapp://callback) and mobile OS does not stops them to do so. As authorization_code is always sent back to redirect URL (in this case myapp://callback), the OS on reception of a redirect to custom URL scheme launches apps matching the scheme randomly. So the code may be sent to your app or may be the hacker app. You cannot prevent this.

Authorization code flow request

Authorization code flow response


Authorization token request

Well, even if they get access to the authorisation code, there is no risk as such because the attacker will not be having the client credentials (client_id, client_secret) to request for an access token. What if they have it too ?

In case of mobile applications, credentials are mostly hardcoded into the app and decompiling it will reveal those. Thus, for public clients it is not recommended to use client secret as it may be compromised.

To mitigate the risk, OAuth 2.0 provides a version of the Authorization code flow which makes use of a Proof Key for Code Exchange (PKCE, pronounced pixie).

When to use PKCE ?

You have a native client, such as an app on a mobile device, or a desktop app and it does not have a secure way to store client credentials for authenticating at the token endpoint.

How it works ?


When the public clients makes the authorization request

  • They first need to create a secret known as code_verifier. This is a cryptographically random string between 43 – 128 characters.
function base64URLEncode(str) {
    return str.toString('base64')
        .replace(/\+/g, '-')
        .replace(/\//g, '_')
        .replace(/=/g, '');

var code_verifier = base64URLEncode(crypto.randomBytes(32));
  • Then use the code_verifier to generate a code_challenge. For clients that can perform a SHA256 hash, the code_challenge is base64 URL encoded string of the SHA256 hash of code_verifier, otherwise plain code_verifier can be used as a challenge.
function sha256(buffer) {
    return crypto.createHash('sha256').update(buffer).digest();
var code_challenge = base64URLEncode(sha256(verifier));
  • Then it includes the code_challenge and a parameter to indicate method used to generate the code_challenge (plain or S256).
  • The authorization server then remembers the code_challenge, code_challenge_method against the authorization code it generates and then redirects the user back to the application with an authorization code.
  • When exchanging the authorization code for a token, client app need not send the client_secret in request, instead it sends the code_verifier generated before making the initial authorization request. This way even if an attacker gets the authorization code they will not have access to code_verifier, hence authorization code is of no use for malicious apps.
  • Authorization server verifies the code_verifier parameter in request by generating the code_challenge as per the code_challenge_method stored against the authorization code. If the verification is successful, server responds with an ID and Access token.


  • Do not store client credentials in native and single page applications.
  • Use PKCE security extension of OAuth 2.0 to securely exchange an authorisation code with access token.



If you have any questions, feel free to comment, I’d love to hear your feedback! Thanks for reading!

Tagged : / / /
%d bloggers like this: