My Handy openssl command list;

Generate a password hash

1
2

openssl passwd -1
openssl passwd -1 -salt <salt> <passwd>

Really handy, if you vitally need to store users passwords in you system

Generate Randomness

1

openssl rand -base64 128

A nice comparison of this wold be with

1

cat /dev/urandom | head -c 128 | base64

Although it seems openssl actually uses /dev/urandom under the hood, when hardware is specified

Generating Keys

RSA Key

1

openssl genrsa -aes256 -out node.key 2048

Public Key

1

openssl rsa -in node.key -pubout -out node.pub.key

DSA key

1
2

openssl dsaparam -genkey 2048 -out node.dsa.key
openssl dsa -in node.dsa.key -out node.key -aes256

or simpler;

1

openssl dsaparam -genkey 2048 | openssl dsa -out node.key -aes256

ECDSA key

1
2

openssl ecparam -genkey -name secp256r1 -out node.ecdsa.key
openssl ec -in node.ecdsa.key -out node.key -aes256

or simpler;

1

openssl ecparam -genkey -name secp256r1 | openssl ec -out node.key -aes256

Self signed Keys

In order to request a new self signed certificate, and a new private key:

1

openssl req -new -x509 -keyout privkey.pem  -newkey rsa:2048

• req : certificate request and certificate generating utility
• new : generates a new certificate request
• x509 : creates a test certificate or a self signed root CA
• keyout : the filename to write the newly created private key
• newkey : creates a new certificate request and a new private key

Also

Examine and verify certificate request

1

openssl req -in node.key -text -verify -noout

Creating a csr with a key

1

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

Requesting a custom siggning certificate

1

openssl x509 -req -days 365 -in node.csr -signkey node.key -out node.crt

or without a csr

1

openssl req -new -x509 -days 365 -key node.key -out node.crt

Then creating a csr from an existing certificate

1

openssl x509 -x509toreq -in node.crt -ou node.csr -signkey node.key

x509

Display the contents of a certificate:

1

openssl x509 -in cert.pem -noout -text

Display the certificate serial number:

1

openssl x509 -in cert.pem -noout -serial

Display the certificate subject name:

1

openssl x509 -in cert.pem -noout -subject

Display the certificate subject name in RFC2253 form:

1

openssl x509 -in cert.pem -noout -subject -nameopt RFC2253

Display the certificate subject name in oneline form on a terminal supporting UTF8:

1

openssl x509 -in cert.pem -noout -subject -nameopt oneline,-esc_msb

Display the certificate MD5 fingerprint:

1

openssl x509 -in cert.pem -noout -fingerprint

Display the certificate SHA1 fingerprint:

1

openssl x509 -sha1 -in cert.pem -noout -fingerprint

Convert a certificate from PEM to DER format:

1

openssl x509 -in cert.pem -inform PEM -out cert.der -outform DER

Convert a certificate to a certificate request:

1

openssl x509 -x509toreq -in cert.pem -out req.pem -signkey key.pem

Convert a certificate request into a self signed certificate using extensions for a CA:

1
2

openssl x509 -req -in careq.pem -extfile openssl.cnf -extensions v3_ca \
        -signkey key.pem -out cacert.pem

Sign a certificate request using the CA certificate above and add user certificate extensions:

1

openssl x509 -req -in req.pem -extfile openssl.cnf -extensions v3_usr -CA cacert.pem -CAkey key.pem -CAcreateserial

Set a certificate to be trusted for SSL client use and change set its alias to “Steve’s Class 1 CA”

1

openssl x509 -in cert.pem -addtrust clientAuth  -setalias "Steve's Class 1 CA" -out trust.pem

Comment and share

Securing local files, it’s a problem solved by a variaty of aps. Though each app are falling
into the falacy of providing their own way to encrypt and package the outputed file.
Now imagine the app developer deciding to discontinue the development and support of the app,
or even worse a known vulnerability of the app goes public (or worse, it never goes public).
Then you data are as unprotective as they were in their raw form. Why shouldn’t be an eay way
to make use of a trusted way? I guess the first solution that pops to our mind is openssl,
right? So why not using just openssl to do the heavy ligting?

TL;DR; evancrypt.sh

Using the force of openssl

Encrypting

So all you need is;

1

openssl aes-256-cbc -salt -in raw.file -out encrypted.aes

Done, you can now delete your raw.file and store your encrypted.aes file into an untrusted store!

Wait, a file? what about a whole directory? Well a file is all we can do, if only we could point
to a directory like it was a file?

tar ladies and getlemen, to the rescue! We can tar -cf our directory and pass the the .tar file to
be encrypted.

Yes you can pipe! So;

1

tar -cf - raw.file.or.directory | openssl aes-256-cbc -salt -out encrypted.aes

Done! With the command above you can securly generate an encrypted file, and being agnostic whether you are
tranforming a file or a dir, as all openssl get is a stream generated from the tar command.

Decrypting

Well an encrypted file, with no way of return has no better value than a deleted file, unless you are trying
to generate some randomnes, in that case all you need is;

1

cat /dev/urandom | head -c 10

and you’ll have your first 10 random bytes.

If on the other hand though, you intend to reuse your files, you are required to decrypt the file, by using
the same Cipher and salt.

1

openssl aes-256-cbc -d -salt -in encrypted.aes -out raw.file

But again, a tar file, has no better value as well, so why not piping the outcome to tar in order to magically
have our file;

1

openssl aes-256-cbc -d -salt -in encrypted.aes | tar -x -f -

The above command should generate back, whatever was passed as input.

Further thoughs

Piping to openssl seems like a super skill that is freely available. Hacking with it can make your saturday evening
more fun than spending it on a sundbed near a tropical beach. Some ideas to get you into the rabbit hole;

Secure one-directional text service

1
2
3
4
5
6
7
8

#server
while true; do nc -lp 4445 | openssl aes-256-cbc -d -salt -k proxyPass | openssl aes-256-cbc -d -salt -k realPass | base64 --decode | cat; done

#proxy
while true; do nc -lp 4444 | openssl aes-256-cbc -salt -k proxyPass | nc localhost 4445; done

#client
while true; do cat /dev/urandom | head -c 10 | base64 | openssl aes-256-cbc -salt -k realPass | nc localhost 4444; done

Done! With the code above, a client can send a text to the server, by passing it first to a proxy. The only job that proxy has
is to double encrypt the message, acting as a “carrier” signal.

Well having a whole setup to only send randomness from one node to an other makes no sense, so please don’t use the code above
as it is.

Comment and share