Latest revision as of 19:04, 4 November 2020

Proper Certs

A properly signed certificate can be accomplished for free with letsencrypt (https://letsencrypt.org/getting-started) First we get the certbot (https://certbot.eff.org)

  yum -y install yum-utils
  yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional
  yum install certbot

We can now generate a new certificate:

 certbot certonly -d endeavour.unh.edu

Or better:

 certbot certonly --standalone

And then fill out the info. For einstein, you would give "Einstein.unh.edu, mail.physics.unh.edu" for the server name. The rest should all pretty much "just work".

- Congratulations! Your certificate and chain have been saved at:
  /etc/letsencrypt/live/endeavour.unh.edu/fullchain.pem
  Your key file has been saved at:
  /etc/letsencrypt/live/endeavour.unh.edu/privkey.pem
  Your cert will expire on 2019-01-10. To obtain a new or tweaked
  version of this certificate in the future, simply run certbot
  again. To non-interactively renew *all* of your certificates, run
  "certbot renew"
- Your account credentials have been saved in your Certbot
  configuration directory at /etc/letsencrypt. You should make a
  secure backup of this folder now. This configuration directory will
  also contain certificates and private keys obtained by Certbot so
  making regular backups of this folder is ideal.

Check the certificates

You can check the certificate easily with:

    certbot certificates

A more detailed check can be done with:

   openssl x509 -in /etc/letsencrypt/live/einstein.unh.edu/fullchain.pem   -text -noout

The output includes the expiration date of the certificate. (See more useful openssl at https://www.sslshopper.com/article-most-common-openssl-commands.html)

Renewal of Certs

With certbot, the renewal of a certificate is really easy:

 certbot  renew

If you want to renew before the expiration is ready:

  certbot --force-renewal  renew

See https://certbot.eff.org/docs/using.htm

Automatic renew can be done with crontab. To add the correct line to the /etc/crontab execute:

  echo "0 0,12 * * * root python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

This will add the line: "0 0,12 * * * root python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew -q" So every day it will check if the cert needs renewing.

Enforcing TLS 1.2 or better, eliminate weak ciphers.

The or better is a problem with Dovecot and Postfix on Centos 7, and will require an upgrade to 8.

For DoveCot: modified the conf.d/10-ssl.conf file:

 #
 # Only allow TLSv1.2, so it will not allow 1 or 1.1
 ssl_protocols = TLSv1.2
 $ Eliminate weak ciphers
 ssl_cipher_list = kEECDH:+kEECDH+SHA:kEDH:+kEDH+SHA:+kEDH+CAMELLIA:kECDH:+kECDH+SHA:kRSA:+kRSA+SHA:+kRSA+CAMELLIA:!aNULL:!eNULL:!SSLv2:!RC4:!MD5:!DES:!EXP:!SEED:!IDEA:!3DES

For Postfix, modified main.cf by adding:

  #
  # Enforce TLS 1.2 or better
  #
  smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
 #
 # Eliminate weak ciphers.                                                                                                                                                                                         
 #                                                                                                                                                                                                                 
 smtp_tls_exclude_ciphers = EXP, MEDIUM, LOW, DES, 3DES, SSLv2
 smtpd_tls_exclude_ciphers = EXP, MEDIUM, LOW, DES, 3DES, SSLv2

These will need to be updated for Centos 8 to permit >=TLSv.1.2

Note: you can check for weak ciphers with: "nmap --script ssl-enum-ciphers -p 995 einstein"

Older Information

A CA-signed certificate provides two important capabilities for your server:

Browsers (usually) automatically recognize the certificate and allow a secure connection to be made, without prompting the user.
When a CA issues a signed certificate, they are guaranteeing the identity of the organization that is providing the webpages to the browser.says RedHat.

The certificate used for LDAP is located at /etc/openldap/root_dn.crt. Do we use the same certificate for everything? If that's only for LDAP then there's no benefit to buying one from an authority, because we're the ones that copy it to each client.

To resign a certificate

To resign a certificate use these two commands:

openssl req -new -key www.physics.unh.edu.key -out www.physics.unh.edu.csr

openssl x509 -req -days 3652 -in www.physics.unh.edu.csr -signkey www.physics.unh.edu.key -out www.physics.unh.edu.crt

Find out what the certificate is

openssl x509 -text -in root_dn.crt

This will print the certificate in text form.

From a remote host, you can check the certificate you get with:

openssl s_client -connect einstein.unh.edu:636

Simple steps to create a self signed certificate

Useful Info:

The openssl documentation and what to do to properly setup certificates is complicated. This was puzzled together and time consuming to figure out. Please be careful when modifying anything with regards to certificates, and please backup the old stuff, and document what you did!!! Some Centos info here: http://www.tecmint.com/enable-ssl-for-apache-on-centos/ and here: http://www.server-world.info/en/note?os=CentOS_5&p=ssl

The problem with RedHat info is that it is all "magic GUI" stuff that does not tell you what is happening. Not useful.

Somewhat Useful:

https://www.unicore.eu/documentation/manuals/unicore6/files/pki-0.2.pdf
https://evilshit.wordpress.com/2013/06/19/how-to-create-your-own-pki-with-openssl/
For LDAP TLS certificate (does not say how to generate): http://www.openldap.org/doc/admin24/tls.html
For LDAP, how to create the certificate: http://www.openldap.org/faq/data/cache/185.html Note CA.sh is not part of our openssl

Create the ROOT certificate

We work in /etc/pki directory and follow the steps from https://www.unicore.eu/documentation/manuals/unicore6/files/pki-0.2.pdf

mkdir -p -m0700 CA/{csr,certs,crl,private,newcerts}

touch CA/index.txt

echo 01 > CA/serial

dd if=/dev/urandom of=CA/private/.rand bs=1k count=16

cp /etc/pki/tls/openssl.cnf /etc/pki/ca-cert.cnf # Edit this file to fix the location stuff and set the rootcert properly

cd CA/

openssl genrsa -aes256 -out private/cakey.pem -rand private/.rand 4096

export OPENSSL_CONF=/etc/pki/ca-cert.cnf

openssl req -new -x509 -sha1 -days 3650 -key private/cakey.pem -out ca.crt # Use old root password without fl$ for pass phrase.

TLS certificate for LDAP

We generate the new certs on Einstein, from the /etc/pki/tls/certs directory. We will need multiple subjectAltNames specified, see: http://wiki.cacert.org/FAQ/subjectAltName The ca-cert.cnf was modified to include the extra names for einstein.

We will work in the /etc/pki directory, even though we are not going to run the pki-ca deamon.

cd /etc/pki/tls/certs

Create a new certificate key. This key is not properly signed. For pass phrase on einstein, I used the old root password without the fl$ prefix.

/usr/bin/openssl genrsa -aes256 2048 > einstein.unh.edu.key

openssl rsa -in einstein.unh.edu.key -out einstein.unh.edu.key # This removes the passphrase. So slapd does not ask for it.

Create the csr:

openssl req -new -key einstein.unh.edu.key -out einstein.unh.edu.csr -config /etc/pki/ca-cert.cnf -subj '/C=US/ST=New Hampshire/L=Durham/O=University of New Hampshire/OU=Nuclear Physics Group/CN=einstein.unh.edu'

Sign it with the local ROOT CA:

openssl ca -config /etc/pki/ca-cert.cnf -policy policy_anything -days 3650 -preserveDN -in einstein.unh.edu.csr -out einstein.unh.edu.crt -extensions v3_req -extfile /etc/pki/ca-cert.cnf

Check the name option:

openssl x509 -nameopt RFC2253 -subject -noout -in einstein.unh.edu.crt

Check the multiple DNS:

openssl x509 -text -noout -in einstein.unh.edu.crt

The new einstein.unh.edu.crt and einstein.unh.edu.key can now be used by openldap. It will ALSO need the CA itself, ca.crt. Modify the /etc/openldap/slapd.conf file to point to them:

TLSCACertificateFile /etc/pki/tls/certs/ca.crt

TLSCertificateFile /etc/pki/tls/certs/einstein.unh.edu.crt

TLSCertificateKeyFile /etc/pki/tls/certs/einstein.unh.edu.key

Now the CA cert (but NOT the einstein.unh.edu* cert) needs to be copied to the CLIENT /etc/openldap/cacerts directory, and a hash link needs to be created:

On Einstein:

scp /etc/pki/CA/ca.crt endeavour:/etc/openldap/cacerts/ca_einstein.crt

ssh endeavour

cd /etc/openldap/cacerts

hash=`openssl x509 -hash -noout -in ca_einstein.crt` && ln -s ca_einstein.crt $hash.0

Now you can test functionality. Restart ldap on Einstein, and on a remote host try:

ldapsearch -H ldaps://einstein.unh.edu -x '(uid=maurik)'

getent passwd

Revoke a certificate from the CA db

Simple

openssl ca -config /etc/pki/ca-cert.cnf -revoke einstein.unh.edu.crt

The config option is there to make sure the right CA database is found.

General Certificate

Create a new certificate key. This key is not properly signed. For pass phrase on einstein, I used the old root password without the fl$ prefix.

/usr/bin/openssl genrsa -aes256 2048 > einstein.unh.edu.key

Instead of -aes256 you can also specify -des3. The 2048 is the number of bits. On RedHat 6+ you can use:

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out $cert.key

Now we can create the csr file (certificate request):

openssl req -new -key einstein.unh.edu.key -out einstein.unh.edu.csr

Provide the pass phrase specified before, and fill in the questions:

-----

Country Name (2 letter code) [GB]:US

State or Province Name (full name) [Berkshire]:New Hampshire

Locality Name (eg, city) [Newbury]:Durham

Organization Name (eg, company) [My Company Ltd]:University of New Hampshire

Organizational Unit Name (eg, section) []:Physics Department

Common Name (eg, your name or your server's hostname) []:Einstein

Email Address []:root@einstein.unh.edu

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

Now, finally, you can sign that request yourself:

For the LDAP csr, you may want to specify the subj.

OBSOLETE AND WRONG: Aaron's fantastic certificate stuff

Fantastic, except, it does not work, and nothing is explained, so it really is not so fantastic at all.

Aaron stopped by for a power cable, and we made him pay for it by telling us that roentgen is our Certificate Authority.

To make a new certificate for a machine ("rood_dn" is the hostname of the server the cert is for):

log onto roentgen
cd /usr/share/ssl/certs
if a certificate already exists for that machine:
1. revoke it with openssl ca -revoke root_dn.crt
2. move it to the old folder
make root_dn.csr
openssl req -new -key root_dn.key -out root_dn.csr -subj '/DC=edu/DC=unh/DC=physics/CN=root'
openssl ca -policy policy_anything -days 3650 -preserveDN -in root_dn.csr -out root_dn.crt
openssl x509 -nameopt RFC2253 -subject -noout -in /root/.ssl/root_dn.crt
copy these newly generated crt, csr, and key files to /etc/openldap/cacerts/ on the machine they were generated for

Difference between revisions of "Certificates"

Latest revision as of 19:04, 4 November 2020

Contents