Skip to main content

I made a GIF!

SSL Management Tasks Revisited

In my May 2011 post "SSL Management Tasks" I included some partially automated scripts for openssl on Windows and Linux/UNIX.  This is a more in depth look at certain openssl tasks and the associated commands.

Private Keys - Public-key (or asymmetric) cryptography uses private keys to decrypt messages and public keys to encrypt them. Generating a private key is the first step to creating a certificate signing request or a self-signed certificate. Run the openssl command:

$ openssl genrsa -out private.key 2048
Explaining the openssl command options in order:
  • "genrsa" The standard openssl command to create a new key using the RSA algorithm. There are other algorithms available, however RSA is preferred.
  • "2048" Use a custom 2048 bit modulus. If omitted, the default is an unacceptable 512 bits. The modulus is essentially the key's size: larger keys equal stronger encryption. Certificate Authorities generally do not accept values greater than 3072 yet keys with an 8192 bit modulus can be quickly generated.
  • "-out" Output the private key to a file.  If omitted, the key is sent to stdout.
Certificate Signing Requests - Before a certificate authority (CA) such as Thawte or Verisign can validate a server's public key certificate, it needs information identifying the server. That information is packaged in a Certificate Signing Request (CSR) and sent to the CA. A CSR is only required if you intend to send it to a CA. Run the openssl command:
 $ openssl req -key private.key -new -out server.csr
Explaining the openssl command options in order:
  • "req" The standard openssl command for X.509 Certificate Signing Request (CSR) management.
  • "-key" Use the provided private key file to sign the CSR. The private key file's modulus determines the resulting public key modulus.
  • "-new" Generate a new CSR from user input.  No input file is provided/required.
  • "-out" Output the private key to a file.  If omitted, the result is sent to stdout.
Self-Signed Certificates - In typical public key infrastructure (PKI) arrangements, a key from a certificate authority (CA) is used to validate a server's public key certificate.  This can be costly and complicated however.  Self-signed certificates only require the client and server interact to securely trade public keys.  Run the openssl command:

$ openssl req \
-key private.key \
-new -x509 \
-days 1440 \
-out public.crt

Explaining the openssl command options in order:
  • "req" The standard openssl command for X.509 Certificate Signing Request (CSR) management.
  • "-key" Use the provided private key file to sign the CSR. The private key file's modulus determines the resulting public key modulus.
  • "-new" Generate a new CSR from user input.  No input file is provided/required.
  • "-x509" Self-sign the CSR as an SSL certificate.
  • "-days" Use a custom number of days before certificate expiration. If omitted, the default is an unacceptable 30 days. The suggested 1440 days is approx. 4 years.
  • "-out" Output the public key to a file.  If omitted, the result is sent to stdout.
Private Key and Self-Signed Certificate One-Liner - Openssl is a command interpreter similar to perl, php or bash.  Therefore openssl standard commands can be combined, performing multiple steps and creating powerful one line directives.  As an example, the two previous tasks, generating a private key and self-signing a certificate, can be done in one step. Run the openssl command:

$ openssl req \
-newkey rsa:2048 -nodes \
-keyout private.key \
-x509 -days 1440 \
-out public.crt

Explaining the openssl command options in order:
  • "-newkey" Generate a new private key file to sign the CSR.
  • "rsa:2048" Generate private key using the RSA algorithm and a 2048 bit modulus.
  • "-nodes" Do not DES encrypt the private key file or prompt for a password.
  • "-keyout" Output the private key to a file.
  • "-x509" Self-sign the CSR as an SSL certificate.
  • "-days" Use a custom number of days before certificate expiration.
  • "-out" Output the public key to a file.  If omitted, the result is sent to stdout.
Exporting as PKCS#12 (.P12) - PKCS#12 files (sometimes referred to as PFX files) are a cross-platform, secure export file format for bundling both the public and private keys.

$ openssl pkcs12 \
-inkey private.key \
-in public.crt \
-name "Friendly Name" \
-export -out bundle.p12

Explaining the openssl command options in order:
  • "-inkey" The private key file used to generate the public key.
  • "-in" The public key file generated from the public key file.
  • "-name" Include a friendly name for compatibility importing the PKCS#12 file later.
  • "-export" A PKCS#12 file will be created, not parsed.
  • "-out" Output the PKCS#12 to a file.  If omitted, the result is sent to stdout.
Conclusion - The openssl suite is a complete certificate management solution.  This post has covers the essentials for a server certificate.  Validating and verifying the resulting files is an almost equally long discussion.  Run the openssl commands:
$ openssl rsa -in private.key -text -noout
$ openssl req -in server.csr -text -noout
$ openssl x509 -in public.crt -text -noout
$ openssl pkcs12 -in bundle.p12 -info -nokeys
Check back soon for a post on those openssl validation tasks.  When writing this post used the following sites extensively:

http://openssl.org/docs/apps/openssl.html
http://en.wikipedia.org/wiki/Digital_certificates
http://en.wikipedia.org/wiki/Asymmetric_key_algorithm

Your feedback is needed! If this post was helpful, incorrect or could be better, please comment below.

Also see these my SSL related posts:
SSL Management Tasks
SSL Management Tasks RevisitedRetrieve SSL certificates

Comments

Jason Antonacci said…
Paul Heinlein has a really excellent OpenSSL Command-Line HOWTO on his site at URI http://www.madboa.com/geek/openssl/ .

Popular posts from this blog

Cisco ASA ICMP packet-tracer

Occasionally devices fail to respond to a ping.  This can result from devices being off-line, having a local firewall enabled or the perimeter firewall configuration.  The Cisco ASA ICMP packet-tracer options differ from the TCP or UDP command options.  An example is below: packet-tracer input outside icmp A.B.C.D 8 0 E.F.G.H The ICMP type is "8" (echo request) with code"0" (none).  There are no options on destination IPv4 address E.F.G.H. Complete ICMP documentation at URL http://www.iana.org/assignments/icmp-parameters/ Complete Cisco ASA packet-tracer documentation at URL http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/p.html#wp1878788

Xfce4 lock screen not working

Xfce4 would not start a screensaver on my Linux system.  Researching it, it ran xflock4 from the command line ad received an error: Property "/general/LockCommand" does not exist on channel "xfce4-session". To fix this, additional configuration needed, but no hacks. First, verify xflock4 and xfconf-query are available. $ which xflock4 xfconf-query /bin/xflock4 /bin/xfconf-query Next  install a lock screen package that provides 'xlock', 'slock', 'i3lock' or similar.  $ sudo yum install -y xlockmore-gtk i3lock Last, add an executable (with options) as /general/LockCommand in the xfce4-session settings. $ xfconf-query -c xfce4-session --create -p /general/LockCommand --set "xlock -mode matrix" --type  string $ xfconf-query -c xfce4-session --create -p /general/LockCommand --set "i3lock -c 000000" --type string Test by running xflock4 from the command line or through the GUI.

X11 Forwarding issue solved

TL;DR Disabling IPv6 necessitates SSHd AddressFamily is "inet" for X11 Forwarding to work. Issue OpenSSH assumes both IPv6 and IPv4 protocols are enabled, and default SSHd AddressFamily value "any" is valid. Quickly skimming the OpenSSH source code, it was not obvious why SSHd does not fail gracefully, selecting only an available IP address family. Therefore, for X11 Forwarding to work correctly, in /etc/ssh/sshd_config we must choose: Defaults - IPv6 enabled and SSHd AddressFamily value " any " Custom - IPv6 disabled and SSHd AddressFamily value " inet " Background PuTTY was not creating a $HOME/.Xauthority file on ssh login and no X11 applications would run, despite setting $DISPLAY.  PuTTY was correctly configured with: X11 Forwarding enabled X display location empty Remote authentication protocol MIT-Magic-Cookie-1 X authority file for local display empty On the initial ssh login there should be a .Xauthority notic