Experimenting with SSL/TLS: few questions

kikinovak · 09-11-2015, 08:11 AM

Hi,

I'm currently experimenting with SSL/TLS, certificates, HTTPS, IMAPS, etc. My goal is to get a more in-depth grasp of some things I've been using until now, sometimes for years, without giving them any second thought. I've already opened a thread about a first question that arose, but I sense there will be more, so here's a more general thread.

I have a spare public server with Slackware64 14.1 running on it. I bought two "sandbox" domain names, slackbox.fr and unixbox.fr, and I'm ready to throw some stuff at this machine. Hear my knuckles crack.

While experimenting, I always try to do some practical and hands-on stuff. So first things first, I simply want to host a secure (static) website for slackbox.fr. Here's my Bind configuration for that domain (file /var/named/zone.slackbox.fr):

Code:

; /var/named/zone.slackbox.fr
$TTL 86400
$ORIGIN slackbox.fr.
@ IN SOA ns.slackbox.fr. hostmaster.slackbox.fr. (
   2015110901   ; sn
        10800   ; refresh (3 heures)
          600   ; retry (10 minutes)
      1814400   ; expiry (3 semaines)
        10800 ) ; minimum (3 heures)
        IN          NS      ns.slackbox.fr.
        IN          NS      nssec.online.net.
        IN          MX      10 mail.slackbox.fr.
slackbox.fr.        A       195.154.65.130
ns      IN          A       195.154.65.130
mail    IN          A       195.154.65.130
www     CNAME               slackbox.fr.
ftp     CNAME               slackbox.fr.
slackware CNAME             slackbox.fr.
freebsd   CNAME             slackbox.fr.

The website's address should be https://www.slackbox.fr. (It works!

)

My first attempt will be with a self-signed certificate, which I create like this:

Code:

# mkdir /etc/ssl/mycerts
# openssl req -new -x509 -days 3650 -nodes -newkey rsa:4096 \
      -out /etc/ssl/mycerts/www.slackbox.fr.pem \
      -keyout /etc/ssl/private/www.slackbox.fr.key
# chmod 0600 /etc/ssl/private/www.slackbox.fr.key
# cd /etc/ssl/certs
# ln -s ../mycerts/www.slackbox.fr.pem .

Here's how I answer the questions (openssl req) above. I know that somehow only the CN (Common Name) is really important here:

Code:

  -----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Gard
Locality Name (eg, city) []:Montpezat
Organization Name (eg, company) [Internet Widgits Pty td]:Microlinux
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:www.slackbox.fr
Email Address []:postmaster@slackbox.fr

My websites on this server are all under /var/www/vhosts. I put a little static webpage under /var/www/vhosts/slackbox-secure/htdocs and then define a stance for it in /etc/httpd/extra/httpd-ssl.conf:

Code:

<VirtualHost 195.154.65.130:443>
DocumentRoot "/srv/httpd/vhosts/slackbox-secure/htdocs"
ServerName www.slackbox.fr:443
ServerAdmin postmaster@slackbox.fr
ErrorLog "/var/log/httpd/slackbox-secure_log"
TransferLog "/var/log/httpd/slackbox-secure_log"
SSLEngine on
SSLCertificateFile "/etc/ssl/certs/www.slackbox.fr.pem"
SSLCertificateKeyFile "/etc/ssl/private/www.slackbox.fr.key"
<FilesMatch "\.(cgi|shtml|phtml|php)$">
    SSLOptions +StdEnvVars
</FilesMatch>
<Directory "/srv/httpd/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>
BrowserMatch "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0
CustomLog "/var/log/httpd/ssl_request_log" \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>

The page displays fine. My first idea is to check it with the SSL Labs report engine. Here's what I get (see attached image).

A few remarks on the SSL Labs report results.

1. The red mention NOT TRUSTED obviously doesn't come as a surprise, since it's a self-signed certificate. So far so good.

2. On the other hand, I'm puzzled about the line "prefix handling - not valid for "slackbox.fr" - CONFUSING".

3. There's also a complaint about a "weak signature algorithm".

Regarding #1: I plan to fiddle with StartSSL.com once I get a grasp on self-signed certificates. This will come a bit later.

Regarding #2: As far as I can tell, the page has to be accessible at both https://slackbox.fr and https://www.slackbox.fr. DNS configuration looks OK for these, but as far as I understand, I would have to create two entries in the server stance, ServerName and ServerAlias... but then, I would have to create two different certificates with two separate common names, one for "slackbox.fr" and another for "www.slackbox.fr". I'm confused.

Regarding #3: clueless for the moment.

Any suggestions?

Cheers,

Niki

PS: looks like a load of work, but this is my idea of fun.

dgrames · 09-11-2015, 08:41 AM

In my bind I use www.domain.com CNAME, not just www. But I know you do not have to support any particular alias, maybe just make sure the domain is redirected to the alias in your httpd.vhosts.conf file.
Also in the httpd.vhosts.conf file you need to state the cyphers to use such as
SSLCipherSuite HIGH:MEDIUM:!RC4:!aNULL:+MD5
SSLProtocol All -SSLv2 -SSLv3

Just my thoughts, besides I wanted to follow this thread.

Don

JohnB316 · 09-11-2015, 11:57 AM

I just went to the https://www.slackbox.fr site from my work laptop running Windows 7 using Google Chrome. I got the message that the site was unsafe to go to. Once I clicked "Advanced" on that Chrome warning and actually went to the page, I got the screen in the attachment. So it works.

jb

Cesare · 09-11-2015, 01:00 PM

Quote:

I plan to fiddle with StartSSL.com once I get a grasp on self-signed certificates.

Word of advice: Don't! The "free" may be tempting, but I found the barely working web pages, the non-working verification process, the abysmal customer support and the hidden costs just too painful. Either invest 8€ into a cheap Comodo certificate or wait for general availability of Mozilla's "Let's encrypt" certificates. While you're still in the learning stage you could have a look at CAcert. Free and easy to use, but unfortunately most clients don't know CAcert's root certificate.

Quote:

... but then, I would have to create two different certificates with two separate common names, one for "slackbox.fr" and another for "www.slackbox.fr".

A single certificate can be valid for more than one domain (aka common name aka CN) by specifying one or more "subject alternative names". In this case you have to use a config file because openssl won't prompt you for the necessary options. The config file could look like this:

Code:

[req]
default_days        = 365 
default_keyfile     = slackbox.key.pem
distinguished_name  = req_distinguished_name
encrypt_key         = no
string_mask         = nombstr
req_extensions      = v3_req

[req_distinguished_name]
commonName          = Common Name
commonName_default  = slackbox.fr

[v3_req]
subjectAltName=DNS:slackbox.fr,DNS:www.slackbox.fr

Note #1: The CN needs to be duplicated in the subjAltName section!

Note #2: If you get a single domain certificate from Comodo (and propably others, too), you don't have to fiddle with the config file or subject alternative names. Just make the request for "slackbox.fr" and they'll add "www.slackbox.fr" for you.

Quote:

Regarding #3: clueless for the moment.

SHA-1 is considered insecure for signing the request, use SHA-256 instead, likely by adding "-sha256" to your command line (I haven't tested this). Only "needed" when you're your own CA and working with self-signed certificates.

kikinovak · 09-11-2015, 04:00 PM

Thanks very much for that detailed information, Cesare. I'll try this out tomorrow, with a clean head. A small related question: what would be a suitable name and location for the config file? Even if it's just a convention.

Cesare · 09-11-2015, 09:49 PM

Name and location is up to you as the config file is needed only once - when generating the certificate request with "openssl req -config ". After that it's for future reference only.

unSpawn · 09-11-2015, 11:22 PM

Quote:

Originally Posted by kikinovak

3. There's also a complaint about a "weak signature algorithm".

In short: generate the CSR with 'openssl req -sha256' [0|1].

kikinovak · 09-12-2015, 06:56 AM

Right, here goes. I've spent the best part of a rainy morning experimenting much more.

One thing I couldn't get to work, no matter how much I googled and tried out every possible suggestion, was the subjectAltName option with several domains. No way to make this work. So I'll keep that for later.

In the meantime, I'd like to automate the certificate creation process as much as possible by putting everything in a configuration file, as suggested, which I would then call with the -config <file> switch.

The command described in the initial post basically works. I'll just add the -sha256 switch, which gives:

Code:

# openssl req -sha256 -new -x509 -days 3650 -nodes -newkey rsa:4096 \
      -out /etc/ssl/mycerts/slackbox.fr.pem \
      -keyout /etc/ssl/private/slackbox.fr.key

With the following answers:

Code:

  -----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Gard
Locality Name (eg, city) []:Montpezat
Organization Name (eg, company) [Internet Widgits Pty td]:Microlinux
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:slackbox.fr
Email Address []:postmaster@slackbox.fr

Before giving the multidomain problem more thought, I'd like to solve another problem first, which is automating the certificate creation process by putting as much as possible into a custom configuration file.

The aim is to put as much as possible in the file itself (say, /etc/ssl/mycerts/slackbox.fr.cfg) and then keep the command to create the self-signed certificate as short as possible.

I've had some partial success with this, but before publishing the result of my attempts, I'd like to ask one of the OpenSSL gurus here what slackbox.fr.cfg should look like to produce the output of the command above, but non-interactively.

Cheers,

Niki

PS: I admit this is a bit harder than I thought. But then, I'm stubborn.

unSpawn · 09-12-2015, 07:15 AM

Quote:

Originally Posted by kikinovak

what slackbox.fr.cfg should look like to produce the output of the command above, but non-interactively.

Maybe I don't get it but you should have an example "openssl.cnf" wherever OpenSSL installed its files?

kikinovak · 09-13-2015, 04:46 AM

Right, here goes. After another rainy day of experimenting, everything works perfectly. I have written a script to automate certificate generation as much as possible. Here it is:

Code:

#!/bin/sh
#
# mkcrt.sh
#
# Script to generate a self-signed certificate for multiple domains like
# example.com, www.example.com, mail.example.com, ftp.example.com, etc.
#
# Usage: copy this script to an appropriate place on the system like
# /root/scripts/ or /etc/ssl/scripts/. Eventually, rename it to something like
# mkcrt.$DOMAIN.sh. Edit it to your needs and run it as root.
#
# Niki Kovacs <info@microlinux.fr>

DOMAIN="slackbox.fr"

SSLDIR="/etc/ssl"
CRTDIR="$SSLDIR/mycerts"
KEYDIR="$SSLDIR/private"
CNFFILE="$CRTDIR/$DOMAIN.cnf"
KEYFILE="$KEYDIR/$DOMAIN.key"
CSRFILE="$CRTDIR/$DOMAIN.csr"
CRTFILE="$CRTDIR/$DOMAIN.crt"

# Testing
# rm -f $CNFFILE $KEYFILE $CSRFILE $CRTFILE

for DIRECTORY in $CRTDIR $KEYDIR; do
  if [ ! -d $DIRECTORY ]; then
    echo 
    echo ":: $DIRECTORY directory doesn't exist."
    echo 
    exit 1
  fi
done

for FILE in $CNFFILE $KEYFILE $CSRFILE $CRTFILE; do
  if [ -f $FILE ]; then
    echo 
    echo ":: $FILE already exists, won't overwrite."
    echo 
    exit 1
  fi
done

cat > $CNFFILE << EOF
[req]
distinguished_name          = req_distinguished_name
string_mask                 = nombstr
req_extensions              = v3_req

[req_distinguished_name]
organizationName            = Organization Name (company)
emailAddress                = Email Address
emailAddress_max            = 40
localityName                = Locality Name
stateOrProvineName          = State or Province Name
countryName                 = Country Name (2 letter code)
countryName_min             = 2
countryName_max             = 2
commonName                  = Common Name
commonName_max              = 64
organizationName_default    = Microlinux
emailAddress_default        = info@microlinux.fr
localityName_default        = Montpezat
stateOrProvinceName_default = Gard
countryName_default         = FR
commonName_default          = $DOMAIN

[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = $DOMAIN
DNS.2 = www.$DOMAIN
DNS.3 = mail.$DOMAIN
DNS.4 = ftp.$DOMAIN
EOF

# Generate private key
openssl genrsa \
  -out $KEYFILE \
  4096 

# Generate Certificate Signing Request
openssl req \
  -new \
  -sha256 \
  -out $CSRFILE \
  -key $KEYFILE \
  -config $CNFFILE

# Self-sign and generate Certificate
openssl x509 \
  -req \
  -sha256 \
  -days 3650 \
  -in $CSRFILE \
  -signkey $KEYFILE \
  -out $CRTFILE \
  -extensions v3_req \
  -extfile $CNFFILE

chmod 0600 $KEYFILE

# Create a symlink in /etc/ssl/certs
pushd $SSLDIR/certs
  rm -f $DOMAIN.crt
  ln -s ../mycerts/$DOMAIN.crt .
popd

echo

The test report on SSL Labs is now perfect, except of course for the trust part, since the stuff is self-signed.

Cheers,

Niki

jpollard · 09-14-2015, 04:05 AM

One minor note - Usually the self signed certificate would be treated as a root certificate, then server certificates can be generated for the servers... and user certificates can be issued to individuals.

It also helps by reducing the problems if/when a certificate gets exposed - it is possible to revoke the exposed certificate, and issue a new one without needing to rebuild the entire PKI tree...

As I recall there are "certificate capability" flags that limit what a certificate can be used for. This helps against spoofing/misuse of a certificate (a certificate issued to a user usually shouldn't be allowed to generate certificates for another server... I think this was how a hack of a Microsoft update server got done. A certificate for a different use wasn't properly identified, and certs it issued were then used to create signed viruses... But I'm not sure of the details on this one - it was quite a while ago.) A "server certificate" should not be able to be used to create "user" certificates either (same problem). One issued for mail shouldn't be usable in a web server...

cendryon · 09-14-2015, 04:39 PM

Hi

I started my own PKI experiments some time ago, my 5 years server certificates are about to expire ;-)

I find this tutorial really good if you want to start building your own PKI.
http://pki-tutorial.readthedocs.org/...est/index.html

Cheers

atelszewski · 09-15-2015, 03:35 PM

Hi,

Have a look here:
1. OpenSSL Certificate Authority
2. easy-rsa

--
Best regards,
Andrzej Telszewski

kfritz · 09-15-2015, 05:38 PM

I find xca to be the antidote to openssl certificate complexity. Slackbuild here.

kikinovak · 09-20-2015, 12:35 AM

The next question that puzzles me is relative to file ownership and permissions. Let me follow up on the example above. I just created a self-signed certificate for the domain "slackbox.fr". The relevant files are:

The certificate: /etc/ssl/mycerts/slackbox.fr.crt ;
The private key: /etc/ssl/private/slackbox.fr.key.

Both files belong to root:root. The private key has permissions rw-------, and I created a symlink /etc/ssl/certs/slackbox.fr.crt which points to the certificate in /etc/ssl/mycerts.

Let's say I want this certificate to be used by the Apache web server and the Prosody XMPP server. Apache runs as user apache and group apache, and likewise, Prosody runs as user prosody and group prosody. If I want these applications to access the *.crt and *.key files, ownership and permissions have to be set accordingly. But right now, the only sane way I've found is to copy these files to the application-specific directories /etc/httpd/certs and /etc/prosody/certs, and give them respectively to the apache user and group, and to the prosody user and group.

And now I vaguely wonder if there is a less cumbersome way so different applications running as different users can "share" a certificate in a standard place between them.

Any suggestions?