Skip to content


June 7, 2007

11th December

Generate key – with alias

Export the key in a certificate  – asks for machine name

Import key in a keystore – aka database – asks for certificate password.

that is it.


Updated: 1st June 2008.

keytool -delete -alias tomcat -keypass changeit
keytool -delete -alias mykey %JAVA%/jre/lib/security/cacerts

keytool -genkey -alias tomcat -keypass changeit -keyalg RSA
keytool -export -alias tomcat -keypass changeit  -file server.crt
C:\Program Files\Java\jdk1.6.0_05\jre\lib\security>keytool -import -file server.crt -keypass changeit -key
store "C:\Program Files\Java\jdk1.6.0_05\jre\lib\security\cacerts"

Yesterday I had tried installing CAS . Central Authentication Server. Provided by JA-SIG Java Architect Special Interest Group. The setup for version 3.0.7 had the demo war file which needed to be modified for the LDAP authentication – the file which needed to be modified was deployerConfigContext.xml and after that downloaded the SPRING ldap with dependency package. This made the CAS Server up and running (of course the demo war)

Next was to configure the client. For this downloaded the Yale CAS java Client jar file. Put it in the lib of manager Tomcat application. Modified the web.xml to use the filters that redirect to the https address of the CAS Server.
Next is to configure SSL in tomcat. For this I needed to understand how keytool works:

Create and store self signed certificate in keystore and then imported by the parties who would need to use it.

“C:\Program Files\Java\jdk1.5.0_03\bin\keytool” -import -file server.crt -keypass changeit -keystore “C:\Program Files\Java\jdk1.5.0_03\jre\lib\security\cacerts

“C:\Program Files\Java\jdk1.5.0_03\bin\keytool” -delete -alias tomcat -keypass changeit

“C:\Program Files\Java\jdk1.5.0_03\bin\keytool” -genkey -alias tomcat -keypass changeit -keyalg RSA

“C:\Program Files\Java\jdk1.5.0_03\bin\keytool” -export -alias tomcat -keypass changeit -file server.cert

“C:\Program Files\Java\jdk1.5.0_03\bin\keytool” -import -file server.crt -keypass changeit -keystore “C:\Program Files\Java\jdk1.5.0_03\jre\lib\security\cacerts

“C:\Program Files\Java\jdk1.5.0_03\bin\keytool” -import -file server.crt -keystore

“C:\Program Files\Java\jdk1.5.0_03\jre\lib\security\cacerts”

1.Create a key: keytool -genkey
2.Get the certificate for that key: keytool -export
3.Give this certificate to the client: keytool -import in the client’s jre

keytool: It’s operations include generation of private/public key pairs, importing and exporting of keys from the keystore, generation of a Certificate Signing Request to a Certification Authority and other admin options such as password changing, listing of keys and deletion of unwanted keys.

Self certified keytool
genkey – certificate created with your public key and self signed.

= create keystore.
= create certificate
= Get it signed by trusted authorized (CA) = Signed X.509 certificate
= create private key (shows certif belongs to someone = encrypt it…)
= signed cert stored with private key
= Import signed certificate into java keystore

= 3 actors = Subject (Alice), Certifying Authority *(Versign/Self Signed) and Relying Party (Ben)
Keystore is a file that is locked by a password (keystore password) and it contains keys and X.509 certificates identified by aliases

SSL provides security by: – Encrypting data packets – Adding Message Authentication Code (MAC)
– Mandatory authentication of the server by the client . 2 steps for SSL – Trust establishment – Key Generation

public key is for decrypting = kept along with the certificate. private key is for encrypting The certificate has the public key for decrypting and with private key data is encrypted. anyone who has the certificate = imported can decrypt the information. The certificate ensures that the communication = for that session cannot be seen by another user. per session data encryption.
Symmetric is where one key alone is used…Asymmetric is where more than one keys are used

From wiki:

Public key cryptography provides a way to avoid this problem. In principle, if Alice wants others to be able to send her secret messages, she need only publish her public key. Anyone possessing it can then send her secure information. Unfortunately, David could publish a different public key (for which he knows the related private key) claiming that it is Alice’s public key. In so doing, David could intercept and read at least some of the messages meant for Alice. But if Alice builds her public key into a certificate and has it digitally signed by a trusted third party (Trent), anyone who trusts Trent can merely check the certificate to see whether Trent thinks the embedded public key is Alice’s. In typical Public-key Infrastructures (PKIs), Trent will be a CA, who is trusted by all participants. In a web of trust, Trent can be any user, and whether to trust that user’s attestation that a particular public key belongs to Alice will be up to the person wishing to send a message to Alice.

In large-scale deployments, Alice may not be familiar with Bob’s certificate authority (perhaps they each have a different CA — if both use employer CAs, different employers would produce this result), so Bob’s certificate may also include his CA’s public key signed by a “higher level” CA2, which might be recognized by Alice. This process leads in general to a hierarchy of certificates, and to even more complex trust relationships. Public key infrastructure refers, mostly, to the software that manages certificates in a large-scale setting. In X.509 PKI systems, the hierarchy of certificates is always a top-down tree, with a root certificate at the top, representing a CA that is ‘so central’ to the scheme that it does not need to be authenticated by some trusted third party.

From Orion:

HTTPS solves both these problems. It guarantees through the usage of certificates the

  • identity of the server
  • optionally, also the identity of the client
  • provide encryption for the communication.

In “public key crypto systems”, every entity is associated with one public and one private key. When two entities communicate both parties use their own private key and the other sides public key, to make sure that only the two entities can talk to each other.

    Only the private key can be used to create a signature, but the public key can be used to verfiy the signature. This means that the private/public key combination means that an entity can guarantee that it knows its private key without giving away what it is.


    A known way of addressing an entity. In some systems the identity is the public key, in others it can be anything from a Unix UID to an Email address to an X.509 Distinguished Name.

    Now, how can a certificate really certify the identity of anyone? The answer is the Certificate Authorities or the CAs. A Certificate Authority is an organization that issues certificates to other organizations that wish to proove their identity. The CA asks the certificate requester to provide information about itself and the CA gives back a certifcate in return. The returned certificate is chained to the root certificate, establishing a chain of trust. In this way someone dealing with a company identifying itself through a certificate issued by a certain CA doesn’t have to trust every company, but it is sufficient to trust the root CA.

    Examples of CAs are Verisign and Thawte. These are root CAs that issue certificates that are chained to their root certificates. There are also CAs that do not provide root certificates but chain to on of the root CA themselves. So if you get a certificate from such a CA, your certificate is linked to the intermediate CA and their certificate is chained to a root certificate.

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: