Difference between revisions of "Certificates"

From Nuclear Physics Group Documentation Pages
Jump to navigationJump to search
Line 17: Line 17:
 
Fill out the info.
 
Fill out the info.
  
 +
- 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.
 +
 
----
 
----
  

Revision as of 16:26, 12 October 2018


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 

Fill out the info.

- 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.


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:

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):

  1. log onto roentgen
  2. cd /usr/share/ssl/certs
  3. 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
  4. make root_dn.csr
  5. openssl req -new -key root_dn.key -out root_dn.csr -subj '/DC=edu/DC=unh/DC=physics/CN=root'
  6. openssl ca -policy policy_anything -days 3650 -preserveDN -in root_dn.csr -out root_dn.crt
  7. openssl x509 -nameopt RFC2253 -subject -noout -in /root/.ssl/root_dn.crt
  8. copy these newly generated crt, csr, and key files to /etc/openldap/cacerts/ on the machine they were generated for