Showing posts with label encryption. Show all posts
Showing posts with label encryption. Show all posts


TLS and SSL certificates cheat sheet

This is a summary for getting a properly-signed certificate to use with a web server. Probably the same or similar process for other servers, e.g. LDAP.

  1. Generate an RSA private key for your server.
  2. Create a Certficate Signing Request (CSR), specifying the above RSA private key as the key.
    1. Verify the CSR.
  3. Send the CSR to a Certificate Authority (CA).
  4. The CA will send back:
    1. Your signed SSL certificate, in several files in several formats. Our CA gives these four:
      1. Certificate with chain, PEM encoded - foobar_example_com.cer
      2. Certificate only, PEM encoded - foobar_example_com_cert.cer
      3. Certificate as PKCS#7, PEM encoded - foobar_example_com.crt
      4. Certificate as PKCS#7 - foobar_example_com.p7b
    2. An intermediate CA certificate file. This can be thought of as a child of the root CA certificate, which is private and protected by the CA. Our CA gives this file:
      1. Root/Intermediate(s) only, PEM encoded - foobar_example_com_interm.cer
    3. Possibly a reverse intermediate CA certificate. I am actually not certain what this is.
In the following, let’s say that the FQDN of your server is

On a Red Hat-like system, all the SSL- and TLS-related files/certificates are in the directory tree based at:


To generate the RSA private key file

# cd /etc/pki/tls/private
# openssl genpkey -algorithm RSA -out -pkeyopt rsa_keygen_bits:2048

The private key is now in:


Keep this key private, i.e. root-only access.

Next, create a CSR using that newly-created key, also specifying the FQDN to be associated with the certificate that you are requesting:

# cd /etc/pki/tls/certs

# openssl req -sha512 -new -key /etc/pki/tls/private/ -out

The CSR is the file

Verify the CSR:

# openssl req -noout -text -in

You will get output showing information in the request. Check for the “Subject” line, that it matches your geographical and company information, etc.

Send the CSR to your CA of choice. They will use that CSR to sign a certificate. The signed certificate will be sent to you, along with an intermediate CA certificate, and possibly a reverse intermediate CA certificate. 

The CA we use at my organization sends back three files:
  • foobar_example_com_cert.cer - the signed certificate
  • foobar_example_com_interm.cer - the intermediate CA certificate
  • foobar_example_com_interm_reverse.cer - the reverse intermediate CA certificate
For Red Hat-like systems, these files should be put in:
  • signed certificate - /etc/pki/tls/certs/foobar_example_com_cert.cer
  • intermediate CA certificate - /etc/pki/tls/certs/foobar_example_com_interm.cer
  • reverse intermediate CA certificate - /etc/pki/tls/certs/foobar_example_com_interm_reverse.cer
For Apache HTTPD setup, modify the file /etc/httpd/conf.d/ssl.conf

<VirtualHost _default_:443>
SSLCertificateFile /etc/pki/tls/certs/foobar_example_com_cert.cer
SSLCertificateChainFile /etc/pki/tls/certs/foobar_example_com_interm.cer

There is one more setting in that VirtualHost section, for the CA certificate bundle: the SSLCACertificateFile. This file is usually provided by a distro package. In the case of RHEL, it is provided by the ca-certificates package. The default value should be:

SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt



Logjam: another day, another https vulnerability

A vulnerability has just been discovered in https, specifically in the Diffie-Hellman key exchange. This arose from the old export restrictions set by the US, so that its law enforcement and security agencies could break encryption used by foreign entities. Ars Technica, as usual, has a good write-up.

The researchers who discovered the flaw have a dedicated website which gives pointers on what to do if you run a web server, or just a browser. They have a server scanner, or you can use the one at Qualys SSL Labs.

Ivan Ristić has some more detail on increasing the strength of DH on Apache. Unfortunately, it may not be supported by the version of Apache you happen to have running.


Another SSL vulnerability - The POODLE Attack

From the Mozilla Security Blog:
SSL version 3.0 is no longer secure. Browsers and websites need to turn off SSLv3 and use more modern security protocols as soon as possible, in order to avoid compromising users’ private information.
Under RHEL 6.5 with Apache httpd, edit /etc/httpd/conf.d/ssl.conf and make sure the protocol line disables both SSLv2 and SSLv3:
SSLProtocol all -SSLv2 -SSLv3
or you can just specify TLS only:
SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2
 Ars Technica has a good explanation.

Scott Helme has a good run down on how to fix this issue, for various servers and browsers.


Software RAID, encrypted volumes, and mount-at-boot

This is a brief HOWTO on manually setting up an encrypted RAID-1 on Fedora 13, via the command line. I used the command line because I discovered that using Palimpsest hid some details, and left me with an encrypted volume that did not mount at boot.

Along the way, I also decided to use the GUID Partition Table (GPT) rather than the more common Master Boot Record (MBR) partition scheme. Palimpsest supports GPT directly. However, to use a command line utility to handle GPT, you can use parted, or you can install the gdisk package available in Fedora. gdisk's interface behaves a lot like fdisk.

First, some preliminaries. My machine was installed with Fedora 13 on a single disk in the usual way. Once everything was installed, I obtained a pair of 500GB hard drives. My aim was to use those as an encrypted software RAID-1 volume for /home. The two drives were /dev/sdb and /dev/sdc. I also wanted to increase the amount of swap available, and have it striped across the three drives.


I used parted to create GPT partition tables, and then a (roughly) 2GB partition for swap and the remainder for the /home RAID.
    myhost> sudo parted /dev/sdb
    GNU Parted 2.1
    Using /dev/sdb
    Welcome to GNU Parted! Type 'help' to view a list of commands.
    (parted) mklabel gpt
    Warning: The existing disk label on /dev/sdb will be destroyed and all data on this disk will be lost. Do you want to continue?
    Yes/No? Yes 
    (parted) p                                                                
    Model: ATA WDC WD5000AAKS-0 (scsi)
    Disk /dev/sdb: 500GB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt
    Number  Start  End  Size  File system  Name  Flags

The, we create the partitions. Warning: the in-app help for mkpart in parted is wrong. The actual syntax is: mkpart PART-NAME [PART-TYPE] START END. Or, you can just type mkpart and you will be prompted for each option. I will give both types of usage below. The abbreviation -1cyl (minus one) stands for the last cylinder of the disk.
    (parted) mkpart swap-sdeb1 linux-swap 0cyl 256cyl
    (parted) p
    Model: ATA WDC WD5000AAKS-0 (scsi)
    Disk /dev/sdb: 500GB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt
    Number  Start   End     Size    File system     Name       Flags
     1      1049kB  2106MB  2104MB  linux-swap(v1)  swap-sdb1

    (parted) mkpart
    Partition name?  []? raid-home-sdb2                                       
    File system type?  [ext2]? ext4                                           
    Start? 256cyl            
    End? -1cyl
    (parted) unit cyl
    (parted) p                                                                
    Model: ATA WDC WD5000AAKS-0 (scsi)
    Disk /dev/sdb: 500GB
    Sector size (logical/physical): 512B/512B
    BIOS cylinder,head,sector geometry: 60801,255,63.  Each cylinder is 8225kB.
    Partition Table: gpt 
    Number  Start   End       Size      File system     Name            Flags
     1      0cyl    255cyl    255cyl    linux-swap(v1)  swap-sdb1
     2      255cyl  60801cyl  60545cyl                  raid-home-sdb2

Then, do the same to /dev/sdc by selecting the device, and running the same commands above with sdc in place of sdb:
    (parted) select /dev/sdc
    Using /dev/sdc

Now, see what you have created:
    myhost> sudo blkid
    /dev/sda1: UUID="4e41d2b8-a62c-4228-a8ec-bd14d7585fda" TYPE="ext4" 
    /dev/sda2: UUID="dad0fa7b-47b9-4c52-a5ad-9dc0264484a9" TYPE="crypto_LUKS" 
    /dev/sda3: UUID="e5d865a1-9cee-458b-911b-773bf1a429bf" TYPE="swap" 
    /dev/mapper/luks-dad0fa7b-47b9-4c52-a5ad-9dc0264484a9: UUID="e10ca302-1932-4ff3-9b49-45a275e3c4f2" TYPE="ext4" 
    /dev/sdc1: UUID="f9f04c2d-c85a-42c3-a368-9a93103f7751" TYPE="swap" 
    /dev/sdb1: UUID="f67ca37b-de6b-4b51-a4db-9dd4ee4c3665" TYPE="swap" 
    /dev/sdb2: UUID="70747600-ea8e-c722-8645-b548b88b1a63"
    /dev/sdc2: UUID="de283446-102b-a904-6249-2fefd5a801bf"


Add the two new swap partitions to /etc/fstab by adding these two lines. Make the priorities (option pri) equal to the priority for the swap partition which is already in the file:
    UUID=f67ca37b-de6b-4b51-a4db-9dd4ee4c3665 swap                    swap    pri=1
    UUID=f9f04c2d-c85a-42c3-a368-9a93103f7751 swap                    swap    pri=1

Then, turn on the new swap partitions by doing: sudo swapon -a. Check that the swap partitions are active:
    myhost> sudo swapon -s
    Filename    Type  Size Used Priority
    /dev/sda3                               partition 2096120 0 1
    /dev/sdb1                               partition 2046968 0 1
    /dev/sdc1                               partition 2055160 0 1

Encrypted RAID for /home

The order of operations is this:
  1. Create RAID
  2. Set up encryption on RAID
  3. Open encrypted device
  4. Create ext4 filesystem
  5. Mount
To create the RAID-1 (mirrored) device:
    myhost> sudo mdadm --create /dev/md0 --level=mirror --raid-devices=2 /dev/sdb2 /dev/sdc2
And, use blkid to find the UUID for /dev/md0 which you will need for the next step. Then, encrypt the volume:
    myhost> sudo cryptsetup --verbose --verify-passphrase --aes-cbc-plain luksFormat /dev/md0

    This will overwrite data on /dev/md0 irrevocably.
    Are you sure? (Type uppercase yes): YES
    Enter LUKS passphrase: 
    Verify passphrase: 
    Command successful.
Next, open the encrypted device by supplying the password. You will also give it a name, which is the string "luks-" followed by the UUID for the /dev/md0 device (71559f74-fb59-439f-9219-8f529b4fc535 in this example), and have a look in /dev/mapper to see the decrypted device.
    myhost> sudo cryptsetup luksOpen /dev/md0 luks-71559f74-fb59-439f-9219-8f529b4fc535
    Enter passphrase for /dev/md0: 
    myhost> sudo ls -l /dev/mapper
    total 0
    crw-rw---- 1 root root 10, 62 Jul 19 11:07 control
    lrwxrwxrwx 1 root root      7 Jul 19 13:49 luks-71559f74-fb59-439f-9219-8f529b4fc535 -> ../dm-1
    lrwxrwxrwx 1 root root      7 Jul 19 11:07 luks-dad0fa7b-47b9-4c52-a5ad-9dc0264484a9 -> ../dm-0
In order that this volume will be mounted at boot, add the following line to the file /etc/crypttab:
    luks-71559f74-fb59-439f-9219-8f529b4fc535 UUID=71559f74-fb59-439f-9219-8f529b4fc535 none
Now, reboot. You will be prompted for a password to access the encrypted drive you created. When it comes back, you may find that the RAID device is no longer /dev/md0 (use the blkid command), but /dev/md127. That does not matter since we will always refer to volumes by their UUIDs which do not change even if the device mapping has changed.

Before you do the following last step, you will have to move your home directory to a different volume first. I created /tmphome, then copied my files over to there, and modified the /etc/passwd file.
    myhost> sudo mkdir /tmphome
    myhost> sudo mv /home/myname /tmphome
    myhost> sudo vipw     Edit and change your home directory to /tmphome/myname
Then, log out and back in.

Now, edit /etc/fstab and add an entry for this new device:
    /dev/mapper/luks-7b06c7df-a893-456f-a950-15135d52bc89 /home                   ext4    defaults        1 1
And mount it: sudo mount -a

Finally, move your home directory back to /home, and change /etc/passwd back. You may want to reboot to see if it all works as you expect.


FireGPG discontinued

FireGPG was a great Firefox extension that added GPG support to Gmail. Unfortunately, the sole developer has decided to discontinue the extension since he does not use Gmail, and it was becoming a chore to update to keep up with Gmail changes. Fortunately, the source is still available.