--- In [email protected], Mohan Poosa <mohanpo...@...> wrote: > > hi all, > > how to create ssl certificate in apache tomcat linux > > can anyone tell the procedure. > > Regards > Mohan > > > > > > [Non-text portions of this message have been removed] >
locate the key under ssl.conf file uncomment the SSLKEY Line under ssl.conf. change the path, where ur key going to reside in. (note -: if u dont have the above conf file then u have to recompile your apache with ssl. Creating Key #openssl req -new -x509 -nodes -out server.crt -keyout server.key you can create out key with one cmd given above. OR For more strong randomization refer below (4 cmnds) 1. $openssl genrsa -des3 -rand file1:file2:file3:file4:file5 -out server.key 1024 2. $openssl rsa -in server.key -out server.pem (if not req do not run this cmd) 3. $openssl req -new -key server.key -out server.csr 4. $openssl x509 -req -days 60 -in server.csr -signkey server.key -out server.crt Explaination in Brief 1. The first step is to create your RSA Private Key. This key is a 1024 bit RSA key which is encrypted using Triple-DES and stored in a PEM The key is generated using the following command, where file1:file2:etc represents the random compressed files. 2. server.pem is encrypted private key and server.key is uncryted private key, so any one can be used to create .csr 3. Once the private key is generated a Certificate Signing Request can be generated. The CSR is then used in one of two ways. Ideally, the CSR will be sent to a Certificate Authority, such as Thawte or Verisign who will verify the identity of the requestor and issue a signed certificate 4. To generate a temporary certificate which is good for 60 days, issue the following command: X.509 specifies, amongst other things, standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm. The x509 command is a multi purpose certificate utility. The Digital Certificate is in the format defined by X.509 v3. The following shows the structure of a typical X509 v3 Digital Certificate Certificate, Version, Serial Number, Algorithm ID, Issuer, Validity, Not Before, Not After, Subject, Subject Public Key, Public Key Algorithm, RSA Public Key,Extensions, Certificate Signature Algorithm,Certificate Signature 5. $openssl verify server.crt verify certificate 6. $openssl x509 -text -in server.crt print certificate SSL working in short CLI --> client (browser) SRV --> server (ssl engine server) CLI -: The client initiates the SSL handshake process by sending a URL starting with the following: https:// to the server. The client initially sends the Web server a list of each encryption algorithm which it supports. Algorithms supported by SSL DES (Data Encryption Standard) SRV - : The Web server next performs the following tasks: The encryption using a private key/public key pair ensures that the data can be encrypted by one key but can only be decrypted by the other key pair SRV - : Selects an encryption algorithm from the list of encryption algorithms supported by, and received from the client. SRV -: Sends the client a copy of its server certificate. CLI -: The client utilizes the copy of the server certificate received from the server to authenticate the identity of the server. and also botains the public key of the server from the server certificate. CLI -: The client also checks that the certificate was issued by a trusted party (usually a trusted root CA), CLI -: that the certificate is still valid and that the certificate is related to the site contacted. CLI -: The client then uses the public key, to encrypt a random symmetric encryption key and CLI -: sends it to the server with the encrypted URL required as well as other encrypted http data. SRV -: The web server decrypts the symmetric encryption key using its private key SRV -: and uses the symmetric key to decrypt the URL and http data. SRV - : The web server sends back the requested html document and http data encrypted with the symmetric key. CLI -: The client decrypts the http data and html document using the symmetric key and displays the information. Explaination The encryption using a private key/public key pair ensures that the data can be encrypted by one key but can only be decrypted by the other key pair. Anybody can send you an encrypted message, that only you will be able to decrypt. You are the only one to have the other key pair, right? In the opposite , you can certify that a message is only coming from you, because you have encrypted it with you private key, and only the associated public key will decrypt it correctly. A certificate, contains information about the owner of the certificate, like e-mail address, owner's name, certificate usage, duration of validity, resource location or Distinguished Name (DN) which includes the Common Name (CN) (web site address or e-mail address depending of the usage) and the certificate ID of the person who certifies (signs) this information. It contains also the public key and finally a hash to ensure that the certificate has not been tampered with. As you made the choice to trust the person who signs this certificate, therefore you also trust this certificate. Usually your browser or application has already loaded the root certificate of well known Certification Authorities (CA) You can sign a certificate using itself, it is called a self signed certificate. All root CA certificates are self signed. More brief How SSL works SSL works in the following way. A browser connects to a Web server. The Web server responds by sending its digital certificate. The server's digital certificate contains the server's public key, the CA's public key, the server's digital signature algorithm, the CA's digital signature, and other pertinent information. The browser can prove the identity of the server and verify the message digest of the server by using the public key taken from the certificate and checking the result against the certificate of the CA that it has. Browsers contain certificates of several CA. You can view them by clicking on the appropriate browser configuration option. The browser recognizes the CA certificate, and since the CA is a trusted third party guaranteeing the identity of the Web server, the Web server is authenticated. SSL generates four session keys, which are only valid for that session. The keys usually expire within 20 to 30 minutes. The keys are: an encryption key for data sent from the browser to the server, an encryption key for data sent from the server to the browser, an authentication key for data sent from the browser to the server, an authentication key for data sent from the server to the browser. This is known as the SSL handshake, and once established, encrypted data is sent across the Internet. The data is encrypted using a symmetric cipher algorithm. This strengthens security by using the secret as another key. At this point someone cannot discover the secret, but they could interrupt the communication by damaging the secret. Someone could pass most of the information back and forth unmodified, but if lucky could successfully garble an important message after the client and the server shared a secret. The side receiving the message will trust and probably believe the garbled message, and act on it. If this does not produce a valid message, the communication can stop immediately. The browser and the Web server can add a Message Authentication Code (MAC) which is a piece of data computed by using a secret and some transmitted data. The message digest algorithm is a way to build a MAC function. Now the chance of a message being intercepted and modified is extremely small. For example, with an MD5 digest algorithm using 128-bit MAC values the chances are 1 in 2128. Your chances of winning the Florida lottery are slightly better than 1 in 224. With these odds one can feel pretty confident that communication between browser and Web server is secure. For Tomcat with ssl chk my next mail B.Sadhiq
