Public Key Infrastructure (PKI)?

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' gt 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
(No Transcript)
8

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

9
(No Transcript)
10

• 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

11
(No Transcript)
12
(No Transcript)
13

• 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

14
(No Transcript)
15
(No Transcript)
16

• Step 4 Installing the Certificate and Key
• cat key.pem cert.pem gtkey-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

17
(No Transcript)
18

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

19

• 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

20
(No Transcript)
21

• 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

22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
25
Creating your Digital Signature
26
Digital Signature

• 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

27
Digital Signature

• 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
• 22bc0bfef5061dc005ea5909e3078a8c
  harpreet_at_HGDRD3

28
Digital Signature

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

29
Digital Signature

• 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
• 7bab75329eb66c4b29dc2a2b8c2f4e37
  harpreet_at_HGDRD3

30
Digital Signature

• 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_at_172.16.1.2./identity.
  pub
• scp id_dsa.pub harpreet_at_172.16.1.2./identity2.p
  ub
• After that we will login on the remote server
  using ssh or telnet the conventional way... with
  a password.

31
Digital Signature

• 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 gtgt authorized_keys
• touch authorized_keys2
• chmod 600 authorized_keys2
• cat ../identity2.pub gtgt authorized_keys2

32
Digital Signature

• 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_at_172.16.1.2
• Try it again, now for version 2
• ssh -2 -v harpreet_at_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.

33
Digital Signature

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

34
Secure Web Service with Tomcat
35
Web service

• Pre-Requisites
• jdk1.5 or greater
• Jakarta-tomcat-5.0.0 or greater
• jetty-6.1.2rc4
• openssl
• Mozilla Firefox(browser)?

36
Web service

• 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/binPATH
• export CLASSPATHjetty6.1.2rc4.jarCLASSPATH
• 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.

37
Web service

• 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-gtPreferences-gtAdvanced-gtView Certificates-gt
  Authorities-gtimport
• 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.

38
Web service

• 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

39
Web service

• 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 keystoreserver.jks

40
Web service

• 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

41
Web service

• Step3Client certificate creation and signing
• Now, we will create our client private key and
  our CSR
• openssl req -new -newkey rsa1024 -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_nam
  e
• And finally we generate our client keystore
• java org.mortbay.jetty.security.PKCS12Import
  ./client/client.p12 ./client/client.jks

42
Web service

• Step4Create 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

43
Web service

• Add the following lines to your configuration
  file server.xml
• lt!-- Define a SSL Coyote HTTP/1.1 Connector on
  port 8843 --gt
• ltConnector
• className"org.apache.coyote.tomcat5.CoyoteCon
  nector"
• port"8843" minProcessors"5"
  maxProcessors"75"
• enableLookups"true"
• acceptCount"10" debug"0" scheme"https"
  secure"true"
• useURIValidationHack"false"gt
• ltFactory className
• "org.apache.coyote.tomcat5.CoyoteServerSock
  etFactory"
• clientAuth"True" protocol"TLS"
• keystoreFile"path_to_server_jks_fi
  le/server.jks"
• keystorePass"export_password_for_s
  erver"
• keystoreType"JKS" /gt
• lt/Connectorgt
• Once this is done, do not forget to restart your
  tomcat server.

44
Web service

• Load the truststore at start up
• export CATALINA_OPTS-Djavax.net.ssl.trustStore
  path_to/ truststore.jks -Djavax.net.ssl.trustSt
  orePassword your_password
• Step5Import a pkcs12 client-certificate into
  your browser
• Go to 'Edit'-gt'Preferences'-gt'Advanced'-gt'View
  Certificates'-gt'Your Certificate'.
• Then import your (client) certificate by click on
  'Import' button.
• Type the following URL in your
  browser...........
• Http//localhost8843