1 / 44

Public Key Infrastructure (PKI) ‏

Public Key Infrastructure (PKI) ‏. PKI using Linux. Installing Linux Based PKI • Installing a CA • Issuing certificates • Revoking certificates and publishing CRLs. # Creating and Using self signed Certificates • We need an installed copy of OpenSSL, which is

kateb
Télécharger la présentation

Public Key Infrastructure (PKI) ‏

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Public Key Infrastructure (PKI)‏

  2. PKI using Linux

  3. Installing Linux Based PKI • Installing a CA • Issuing certificates • Revoking certificates and publishing CRLs

  4. # Creating and Using self signed Certificates • We need an installed copy of OpenSSL, which is available from Http://www.openssl.org/. • First, we create a directory where we can work. $mkdir CA $cd CA $mkdir newcerts private The CA directory will contain: * Our Certificate Authority (CA) certificate. * The database of the certificates that we have signed. * The keys, requests, and certificates we generate.

  5. The CA/newcerts directory will contain a copy of each certificate we sign. The CA/private directory will contain our CA private key. Without it, we will not be able to sign or renew any new certificates. #Our next step is to create a database for the certificates we will sign: $ echo '01' > serial $ touch index.txt #Now we are going to create a minimal configuration of our own in this directory. $ vi openssl.cnf

  6. # Now download the configuration data for openssl and paste it in openssl.cnf file, that we created. Step 1:Creating a Root Certificate $ openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 3650 - config ./openssl.cnf • This process produces two files as output: * A private key in private/cakey.pem . * A root CA certificate in cacert.pem In order to protect unauthorized use of our CA certificate, it is “passphrase” protected.

  7. # Displaying the contents of CA cert. $openssl x509 -in cacert.pem -noout -text / dates / purpose # Creating a Certificate We can create any number of certificates for installation into our SSL applications .The procedure involves : *Creating a private key, *Certificate request, and then *Signing the request to generate the certificate.

  8. Step 2: Creating a Certificate Signing Request $openssl req -new -nodes -out req.pem -config ./openssl.cnf This process produces two files as output: * A private key in key.pem. The private key is necessary for SSL encryption. * A certificate signing request in req.pem When the certificate expires, the request can be used again to create a new certificate with a new expiry date. # We can view the contents by: $openssl req -in req.pem -text -verify -noout

  9. Step 3: Signing a Certificate $openssl ca -out cert.pem -config ./openssl.cnf – infiles req.pem This process updates the CA database, and produces two files as output: *A certificate in CA directory : cert.pem *A copy of the certificate in newcerts directory Again, you can inspect the certificate: $openssl x509 -in cert.pem -noout -text -purpose

  10. Step 4: Installing the Certificate and Key $cat key.pem cert.pem >key-cert.pem After this step, we have three installable components: * A private key in key.pem. * A certificate in cert.pem * A combined private key and certificate in key-cert.pem Step 5:Distributing the CA Certificate This step stops the clients from complaining about untrusted certificates. Send cacert.pem to anyone who is going to use our secure servers, so they can install it in their browsers, mail clients, etc. as a root certificate. $ openssl verify -CAfile cacert.pem cert.pem

  11. Step 6: Renewing Certificates The certificate chain can break due to certificate expiry : * The certificates you signed with your root certificate have expired. * The root certificate itself has expired. # In the first case, there are two options. We can either generate new certificate signing requests and sign them as described above, or We can re-sign the original requests(If we kept them)‏ # In the second case, we have to do some work. A new root CA certificate must be created & distributed, and then your existing certificates must be recreated or re-signed.

  12. We cannot issue two certificates with the same Common Name, which is why the expired certificate must be revoked. The certificate is in the newcerts directory; we can determine its filename by browsing index.txt and searching for the Common Name (CN) on it. # Creating another Certificate $openssl req -new -nodes -out otherreq.pem -config ./openssl.cnf $openssl ca -out othercert.pem -config ./openssl.cnf - infiles otherreq.pem

  13. # The filename is the index plus the extension ".pem", for example "02.pem". To revoke a certificate: $openssl ca -revoke newcerts/02.pem -config ./openssl.cnf #Now that the certificate has been revoked, & we can re-sign the original request, or create and sign a new one. Step 7:Creating CRLs CRLs should be created regularly and made available to the users of our CA. CRLs can be created without having ever revoked a certificate. However, if you revoke a certificate, a new CRL should be generated immediately. $openssl ca -gencrl -crldays 31 -config ./openssl.cnf -out rootca.crl

  14. Creating your Digital Signature

  15. Creating A Key : When you want to use ssh with keys, the first thing that you will need is a key. To create the most simple key, with the default encryption, open up a console, and enter the following command : $ ssh-keygen The ssh-keygen program will now generate both your public key(identity.pub) and your private key(identity). Your keys are stored in the .ssh/dir in your home directory Digital Signature

  16. This will output the following : Generating public/private rsa1 key pair. Enter file in which to save the key : /home/harpreet/.ssh/identity Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/harpreet/.ssh/identity. Your public key has been saved in /home/harpreet/.ssh/identity.pub. The key fingerprint is: 22:bc:0b:fe:f5:06:1d:c0:05:ea:59:09:e3:07:8a:8c harpreet@HGDRD3 Digital Signature

  17. Creating a version 2 keypair In our example we will create a keypair using dsa encryption. $ ssh-keygen -t dsa The file identity2 contains your version 2 private key & the file identity2.pub contains your version 2 public key. Placing the public key on the remote server To be able to log in to remote systems using your pair of keys, you will first have to add your public key on the remote server to the authorized_keys (for version 1) file, and the authorized_keys2 (for version2) file in the .ssh/ directory in your home directory on the remote machine. Digital Signature

  18. Which will output the following : Generating public/private dsa key pair. Enter file in which to save the key : /home/harpreet/.ssh/identity2 Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/harpreet/.ssh/identity2 Your public key has been saved in /home/harpreet/.ssh/identity2.pub The key fingerprint is: 7b:ab:75:32:9e:b6:6c:4b:29:dc:2a:2b:8c:2f:4e:37 harpreet@HGDRD3 Digital Signature

  19. In our example we will assume you don't have any keys in the authorized_keys files on the remote server. (Hint: If you do not have a remote shell, you can always use your own useraccount on your local machine as a remote shell (ssh localhost)). Now, we will upload the public keys to the remote server $ cd .ssh/ $ scp identity.pub harpreet@172.16.1.2:./identity.pub $ scp id_dsa.pub harpreet@172.16.1.2:./identity2.pub After that we will login on the remote server using ssh or telnet the conventional way... with a password. Digital Signature

  20. When you are logged in you should create a .ssh directory, and inside the .ssh/ directory create an authorized_keys and an authorized_keys2 file and add the keys to the files. Adding the public key for version 1 & version 2 : $ mkdir .ssh $ cd .ssh $ touch authorized_keys $ chmod 600 authorized_keys $ cat ../identity.pub >> authorized_keys $ touch authorized_keys2 $ chmod 600 authorized_keys2 $ cat ../identity2.pub >> authorized_keys2 Digital Signature

  21. Log in using your key : To log in using your key use the ssh command. We will add -1 to make sure we are using SSH Protocol version 1. $ ssh -1 -v harpreet@172.16.1.2 Try it again, now for version 2 $ ssh -2 -v harpreet@172.16.1.2 SSH Keys with a passphrase : If I lost my key, the finder would be able to access every system on which I installed my public key. To sort out this problem we can use a passphrase on our key. This does nothing more than configuring your key so that you have to enter a passphrase to use it. Digital Signature

  22. After that use the command "ssh -v -i .ssh/identity" to test it. The ssh program will ask you for the passphrase. After you enter your passphrase, it will load the key and use it to authenticate you using ssh. Digital Signature

  23. Secure Web Service with Tomcat

  24. Pre-Requisites: jdk1.5 or greater Jakarta-tomcat-5.0.0 or greater jetty-6.1.2rc4 openssl Mozilla Firefox(browser)‏ Web service

  25. Pre-setup: Create pki directory - mkdir pki Create public,private,client directories under pki Set the environment variables JAVA_HOME, PATH, CLASSPATH as follows: Create one “library” file which contains the above details. export JAVA_HOME= /usr/local/bin/jdk1.5.0_07/ export PATH=/usr/local/bin/jdk1.5.0_07/bin:$PATH export CLASSPATH=jetty6.1.2rc4.jar:$CLASSPATH # JAVA_HOME will be where you have installed java # Place bin directory of jdk in PATH environment variable # We place jar file of 'jetty6.1.2rc4.jar' in the CLASSPATH environment variable. Web service

  26. Step1: Creation of CA # Create private key for CA, ca.key in private directory: $ openssl genrsa -des3 -out private/ca.key 1024 # After that you can self-sign your CA certificate : $ openssl req -new -x509 -key private/ca.key -out public/ca.crt -days 3600 # When you create your own CA you can record it in your browser's certificate authorities list : Edit->Preferences->Advanced->View Certificates-> Authorities->import Any certificate signed by your CA will automatically be trusted by your browser. Now we have our CA certificate, and we can use it to sign our server certificate. Web service

  27. Step2: Create and sign your server certificate In this step we will cover server-certificate creation, signing it with your own CA and import it in a JKS keystore for a use with Tomcat. # First we generate the server private key encoded(des-3), and protected with a strong password. $ openssl genrsa -des3 -out private/server.key 1024 #Now we can create our server certificate signing request (csr). $ openssl req -new -key private/server.key -out server.csr Web service

  28. # You can sign your server certificate with your CA as: $ openssl x509 -req -days360-in server.csr-CA public/ca.crt- CAkey private/ca.key-CAcreateserial-out public/server.crt We are still to try to make server authentication work. So we are going to create a pkcs12 file (with server.crt and server.key)that we will translate to JKS keystore:server.jks Web service

  29. # This keystore will contain the private and public key necessary to encrypt a message on the server side for the Tomcat web server. We create our pkcs12 file with openssl with the following command: $ openssl pkcs12 -export -in public/server.crt -inkey private/server.key -out server.p12 # Now,we need to transform the pkcs12 to a keystore file. $ java org.mortbay.jetty.security.PKCS12Import server.p12 server.jks # Now you have a JKS keystore that you can use with your Tomcat web service. You can also check the content of your keystore by : $ keytool -v -list -keystore server.jks Web service

  30. Step3:Client certificate creation and signing # Now, we will create our client private key and our CSR $ openssl req -new -newkey rsa:1024 -nodes -out client/client.req -keyout client/client.key # Then sign the csr with your own CA $ openssl x509 -CA public/ca.crt -CAkey private/ca.key-CAserial public/ca.srl -req -in client/client.req -out client/client.pem -days 100 # Export client certificate as keychain in pkcs12 keystore $ openssl pkcs12 -export -clcerts -in client/client.pem -inkey client/client.key -out client/client.p12-name your_certificate_client_name # And finally we generate our client keystore: $ java org.mortbay.jetty.security.PKCS12Import ./client/client.p12 ./client/client.jks Web service

  31. Step4:Create and populate a trust-store for Tomcat In this step we will create a trust-store for Tomcat. This trust-store will hold the public key of our own CA. We will have to generate a keystore containing a dummy keychain, delete it, to have a clean and empty JKS Java keystore. keytool -genkey -alias dummy -keyalg RSA -keystore truststore.jks # Now delete the alias dummy, to have an empty trust-store: $ keytool -delete -alias dummy -keystore truststore.jks That's it, now we are ready to import our CA public key,import: $ keytool -import -v -trustcacerts -alias my_ca -file public/ca.crt -keystore truststore.jks Web service

  32. Add the following lines to your configuration file server.xml <!-- Define a SSL Coyote HTTP/1.1 Connector on port 8843 --> <Connector className="org.apache.coyote.tomcat5.CoyoteConnector" port="8843" minProcessors="5" maxProcessors="75" enableLookups="true" acceptCount="10" debug="0" scheme="https" secure="true" useURIValidationHack="false"> <Factory className = "org.apache.coyote.tomcat5.CoyoteServerSocketFactory" clientAuth="True" protocol="TLS" keystoreFile="path_to_server_jks_file/server.jks" keystorePass="export_password_for_server" keystoreType="JKS" /> </Connector> Once this is done, do not forget to restart your tomcat server. Web service

  33. # Load the truststore at start up: export CATALINA_OPTS=”-Djavax.net.ssl.trustStore = path_to/ truststore.jks -Djavax.net.ssl.trustStorePassword =your_password” Step5:Import a pkcs12 client-certificate into your browser Go to 'Edit'->'Preferences'->'Advanced'->'View Certificates'->'Your Certificate'. Then import your (client) certificate by click on 'Import' button. Type the following URL in your browser........... Http://localhost:8843 Web service

More Related