Tag: OpenSSL

Last few weeks, I have been pulled into an interesting gig for demonstrating security for _____  SOA/XML Web Services and Java EE applications…. so I had a chance to play with some untold security features of Solaris 10. KSSL is one of the unsung yet powerful security features of Solaris 10.  As the name identifies, KSSL is a Solaris Kernel Module that helps representing server-side SSL protocol to help offloading operations such as SSL/TLS based communication, SSL/TLS termination and reverse-proxying for enduser applications. KSSL takes advantage of Solaris Cryptographic Framework (SCF), to act as an SSL proxy server performing complete SSL handshake processing in the Solaris Kernel and also using the underlying hardware cryptographic providers (SSL accelerators, PKCS11 Keystores and HSMs) to enable SSL acceleration and supporting secure key storage.

Before I jump into how to use KSSL for offloading SSL operations, here is some compelling aspects you may want to know:

  1. Helps non-intrusively introduce an SSL proxy server for Web servers, Java EE application servers and also applications that does’nt implement SSL.
  2. KSSL proxy listens to all secured requests on the designated SSL port (ex. HTTPS://:443)  and renders a cleartext traffic via reverse proxy (ex. HTTP://:8080) port for the underlying Web or application server. All SSL operations including the SSL handshake and session state are performed asynchronously in the Solaris Kernel and without the knowledge of the target application server.
  3. KSSL automatically uses SCF for offloading operations to underlying hardware cryptographic providers with no extra effort needed.
  4. Manages all the SSL certificates independently supporting most standard formats (ex. PKCS12, PEM),  the key artifacts can be stored in a flatfile or a PKCS11 conformant keystore (If you are worried about loosing the private key).
  5. Supports the use Solaris zones, where each IP identified zone can be configured with a KSSL proxy
  6. Delivers 25% – 35% faster SSL performance in comparison with traditional SSL configurations of most popular Web servers and Java EE application servers.
  7. KSSL can be used to delegate Transport-layer security and the applications may choose to implement WS-Security mechanisms for message-layer security.

Those are some compelling aspects of KSSL that are hard to ignore…. if you really understand the pain from performance overheads associated with SSL/TLS :-)   As I verified, KSSL works well with most common Web servers and Java EE applications servers.


Try it yourself

Certainly it is worth a try…and you should able to do it very quickly than configuring SSL for your web sever !


  • Obtain your server SSL and CA certificates. If you just want to test-drive KSSL and considering to using a self-signed OpenSSL certificate.. just follow the example commands and make sure that your web server hostname is correct. If you choose to use a flatfile based SSL keystore, KSSL requires to have all your certificate artifacts (including private key and certificates) in a single file.  If you need more OpenSSL help, read my earlier post.

          Ex. To create a self-signed server certificate using OpenSSL (in PEM format).

    openssl req -x509 -nodes  -days 365 -subj
    -newkey rsa:1024  -keyout myServerSSLkey.pem -out mySelfSSLcert.pem

           Ex.  Concatenate the server certificates in a single file.

    cat mySelfSSLcert.pem myServerSSLkey.pem > mySSLCert.pem
  • Configure the KSSL proxy service,  assuming the secured requests are forwarded to an SSL port (ex. 443) and the reverse-proxy of your backend Web server listens to a non-SSL port (ex. 8080). Use -f option to identify the certificate fomat, to represent PEM (-f pem) and to represent PKCS12 (-f pk12).  If the certificates are located in a HSM/PKCS11 Keystore, use -f pkcs11 to identify the token directory, -T to identify the token label and -C to identify the certificate_subject.

          Ex. To configure the KSSL proxy service with SSL Port 443 and reverse-proxy port is 8080 using PEM based certificates and the passphrase stored in file (ex. password_file).

           ksslcfg create -f pem -i mySSLCert.pem -x 8080 -p password_file webserver_hostname 443
  • Verify the KSSL proxy service under Solaris Service Management Framework (SMF) controls, the KSSL services is identified with FMRI svcs:/network/ssl/proxy.
                    svcs - a | grep "kssl"
  •  Assuming your webserver in the backend listens at port 8080, you should able to test the SSL configuration provided by the KSSL proxy.  Open your browser, goto https://webserver_host:443/ you should be prompted by the SSL dialog warning to accept a self-signed certificate.
  • More importantly, if your Solaris host is a Sun CMT server (based on UltraSPARC T1/T2 processor), KSSL automatically takes advantage of the cryptographic acceleration and no additional configuration is necessary.

Here is an unofficial benchmark that highlights performance comparisons with KSSL and other SSL options.  The following shows the latency of an Web application running on Oracle Weblogic server using different SSL configurations (Certificate using RSA 1024) on a Sun CMT server (T5440) – To interpret the graph, make a note “Smaller the Latency means Faster”.


Adopting to Sun CMT servers (based on UltraSPARC T1/T2 processors) helps delivering on-chip cryptographic acceleration for supporting SSL/TLS and its cryptographic functions. With KSSL based SSL deployment, you will atleast get an additional 30% performance advantage while comparing with other Web server based SSL deployments. I heard that Intel Nehalem EX processors are expected to provide similar on-chip crypto capabilities, not sure !  Either way, using KSSL is a no brainer and it works.  If you are itching the head to provide transport-layer security for your applications, this could be easiest way to go !  Ofcourse, it can help you score some points in those IT infrastructure security assessment checklists verifying for PCI-DSS, FISMA, HIPPA and/or similar regulatory/industry compliance mandates !  :-)

Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

 Are you test driving Amazon S3 cloud as your backup storage and worried about your data security ?  Now, Amazon S3 users can have a compelling encrypted backup solution by adopting to OpenSolaris and ZFS.  Few months ago, I had my first experience with ZFS Automatic Snapshots which allows to backup and preserve the filesystem at timed intervals.  Last week I noted from Glenn Brunette that now we can store and retrieve Encrypted ZFS Automatic Snapshots to and from Amazon S3 Cloud.  Thanks to Project Kenai initiative, it just introduced the ZFS Backup To S3  and S3-Crypto tools together referred to as Cloud Safety Box (CSB) that allows to integrate the ZFS Automatic Snapshots with full-fledged encryption support using Solaris Cryptographic Framework or OpenSSL.  The solution can also take advantage of cryptographic accelerators including On-chip cryptographic acceleration provided by Sun Niagara T1/T2 platforms.


The following diagram depicts the operational model of storing and retrieving encrypted ZFS snapshots to Amazon S3 storage cloud.  You just had the highlights… if you want to try it out I suggest you to take a look at the detailed instructions here at Project Kenai.

Encrypted ZFS Automatic Snapshots

Encrypted ZFS Automatic Snapshots (Source: Project Kenai)

Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

Access control exploits, user credential exposures and related security compromises are becoming increasingly common in Web 2.0 world ! Most of these issues pertain to broken or insufficient authentication controls and flawed credential management that allows attackers to compromise vulnerable applications by stealing or manipulating credentials such as passwords, keys, session cookies and/or impersonating another user through forged or guessed credentials.  Any such access control failure leads to unauthorized access and disclosure of underlying application databases, user accounts and stored data.  Most access control related vulnerabilities are due to the inherent application-specific weakness and failure to enforce authentication mechanisms, verify authentication credentials, lack of policy enforcement prior to granting or denying access to the underlying database.

This is my second installment of work exploring MySQL security features to enforce stronger authentication controls and defend against unauthorized disclosure of user account credentials and application-related database tables.  In simpler terms, I will be uncovering a set of MySQL security mechanisms intended for the following:

  1. X.509 certificate-based  MySQL authentication
  2. Enabling host verification to cease access from untrusted hosts
  3. Restricting remote access to MySQL database
  4. Disable unauthorized access to local files
  5. Securing MySQL user accounts, passwords and access privileges
  6. Data encryption using AES

X.509 Certificate based MySQL authentication

Enforcing X.509 v3 Certificate authentication allows clients to authenticate the MySQL database server using X.509 certificates and its attributes. To enable certificate based authentication,  the MySQL  GRANT statement allows to limit user access to request X.509 certificate by specifying a set of options.  To connect the client must specify the certificates using  –ssl-ca  (CA certificate),  –ssl-cert (Client certficate) and -ssl-key (Client key).


a)  The REQUIRE X509  option allows user to provide a valid X.509 certificate, where the signing authority should be verifiable using the CA certificate. 


mysql>  GRANT  ALL PRIVILEGES  ON  test.*  TO ‘ramesh’@'localhost’  IDENTIFIED  BY  ‘password’  REQUIRE  X509;


b) The REQUIRE SUBJECT  ..  AND ISSUER  .. option allows the user to provide a valid X.509 certificate containing the subject information of the user and the certificate issued by a specific CA  as defined in the GRANT statement. The user’s certificate and the specified SUBJECT and ISSUER attributes are verified against the information provided with GRANT statement.


mysql>  GRANT  ALL PRIVILEGES  ON  test.*  TO ‘ramesh’@'localhost’  IDENTIFIED  BY  ‘password’  REQUIRE SUBJECT  ‘/C=US/ST=Massachusetts/L=Burlington/O=Sun Microsystems/CN=Ramesh Nagappan/Email =Ramesh.Nagappan@mysqltest.com’  AND ISSUER ‘/C=US/ST=Massachusetts/L=Burlington/O=Sun Microsystems/CN=SunTest CA’;


c) In addition to SUBJECT and ISSUER, the user’s certificate can be identified with the specific CIPHER .  The REQUIRE CIPHER option allows to specify the required algorithm to grant access to the database.


mysql>  GRANT  ALL PRIVILEGES  ON  test.*  TO ‘ramesh’@'localhost’  IDENTIFIED  BY  ‘password’  REQUIRE SUBJECT  ‘/C=US/ST=Massachusetts/L=Burlington/O=Sun Microsystems/CN=Ramesh Nagappan/Email =Ramesh.Nagappan@mysqltest.com’  AND ISSUER ‘/C=US/ST=Massachusetts/L=Burlington/O=Sun Microsystems/CN=SunTest CA’   AND  CIPHER ”DHE-RSA-AES256-SHA’;


d)  To allow access to user with SSL-enabled connection.

GRANT  ALL PRIVILEGES  ON  test.*  TO ‘ramesh’@'localhost’  IDENTIFIED  BY  ‘password’  REQUIRE SSL;



Trusted Host Verification

Host identification helps to allow the user requests initiated from the specified host only. If the user and hostname doesnot match the specified host the server will deny access to the database.  To enable host verification, the MySQL  CREATE USER and GRANT statements allows to specify the user assigned with a target hostname.


a)  The CREATE USER allows to specify the user assigned to a specific hostname. The user will be allowed access only if the request orginated from the specified hostname.

mysql>   CREATE  USER  ‘ramesh’@'localhost’  IDENTIFIED BY ‘some_password’;

 The above statement creates an user ‘ramesh’ assigned to hostname ‘localhost’.  This means ‘ramesh’@'localhost’ account can be used only when connecting from the localhost. 


b)  The GRANT statement allows to define user privileges on a database table only when the user is accessed from a specified host.  If the user connected from a different host the access will be denied.

mysql>   GRANT SELECT,INSERT,UPDATE  ON  test.*  TO  ‘ramesh’@'east.sun.com’;



Disabling Remote Access from Network 


If the MySQL database is accessed locally by the coexisting appplications, remote access from the network can be disabled.  To disable remote access via network,  you may add skip-networking under the [mysqld] section of my.cnf or start mysqld using the –skip-networking option.  To enable MySQL listen to a specific host IP address, you need to set the following attribute in the [mysqld] section of my.cnf  as follows:




Disabling unauthorized access to Local files

To disable unauthorized access or reading of local files, particularly to prevent applications access local files using SQL injection attacks – you may add the set-variable=local-infile=0 under the [mysqld] section of my.cnf .

Also, run MySQL as run as an user with minimized privileges so that any potential attacks does not result in damages to the operating system and other processes. 



Securing MySQL User Accounts, Passwords and Privileges


a) To prevent unauthorized and anonymous access to the server,  first remove the test database and all user accounts (with the exception of root account).

mysql> drop database test;
mysql> use mysql;
mysql> delete from db;
mysql> delete from user where not (host=”localhost” and user=”root”);
mysql> flush privileges;

mysql> quit;


b)  Change the MySQL root password and make sure the password is done via mysql> command line.  It is a bad practice, to change passwords via mysqladmin – u root password as the password can be accessed via “ps -aef”  (Solaris) “ps -aux” (Linux) command or by reviewing the Unix command history files. 


c)  Passwords are usually visible as plain text in SQL statements especially while executing CREATE USER, GRANT and SET PASSWORD statements. If the MySQL server is logging the SQL events and action to tables, then make sure those tables are protected from unauthorized users.


d) Change the default administrator account name from ‘root’ to a harder to guess ‘username’.  This would help defend against hackers performing dictionary/brute-force guessing attacks for administrator credentials.

mysql>  update user set user=”mysqlgeek’ where user=”root”;
mysql> flush privileges;


e) MySQL stores user accounts and its passwords in mysql.user table. Disable access to this table for any non-administrator users.


f)  Enforce the ‘principle of least privileges’ by granting minimum privileges for performing the required actions especially for user accounts that connects to the MySQL database from external applications. Do not grant privileges at the database level, MySQL allows to define privileges as required at the Table and Column level.

    grant <privileges> <column> on <database>.<table> to <login-name>@<FQDN-or-IP> identified by <password>;


Data Encryption using AES

MySQL supports data encryption functions by providing support for AES (Advanced Encryption Standard) and DES (Triple-DES) algorithms.  It is important to note, the encryption function return binary strings as BLOBS, so you may need to store the encrypted data in columns of BLOB or VARBINARY data types. MySQL provides AES_ENCRYPT( ) and AES_DECRYPT ( )  to facilitate AES based encryption and decryption  and DES_ENCRYPT( ) and DES_DECRYPT ( )  to facilitate Triple-DES based encryption and decryption  operations.


For example:


mysql>  insert into mytable (username, password)  VALUES (‘nramesh’,  AES_ENCRYPT(‘g01ns@n3′, ‘myaeskey’));


mysql>  select username, AES_DECRYPT(password, ‘myaeskey’) from mytable;

| username | des_decrypt(password, ‘myaesencryptionkey’)  |
| nramesh | g01ns@n3 | 
| bobama | s@v3u5a |


It is important to note, the encryption KEY must be provided by the application user to MySQL. It means that MySQL does’nt provide mechanisms for generating the keys. Also it is critical to store the key for supporting further decryption operations.



That’s all folks. I will revisit again on my next MySQL security project …till then let me practice wearing an Oracle shirt :-)

Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

Web 2.0 applications are proliferating and it has become widely popular for delivering dynamic user-generated content, information collaboration, data mashups, social networking and Web services. Building security for Web 2.0 applications pose several daunting challenges to Web 2.0 developers as these applications are publicly accessible and it blindly opens door to several intentional/unintentional abuses and malicious practices including data interception and manipulation by cyber-criminals.  Unfortunately, Web 2.0 has no silver bullet or one-size fits all security solution ! Interestingly, the most common Web 2.0 security threats pertain to the inherent flaws with the application design, deployment architecture and its failure to proactively identify the potential application-level risks  and mitigate them with appropriate countermeasures.


Lately Web 2.0 application databases have become an easier target for cyber criminals – as it is transparent to user with rich-client applications and draws close proximity to the network perimeter ignoring the traditional logical-tiers of insulation considered with multi-tier architectures (such as Java EE). If we explore the existing Web 2.0 attack patterns and attempt to identify the potential security threats and exploits of Web 2.0 databases, we will find the most common vulnerabilities pertain to the following issues:

·         Eavesdropping database connections

·         Un-trusted application clients

·         Insufficient authentication controls

·         Insecure database access execution privileges

·         Unauthorized disclosure of user account credentials

·         Unauthorized access to application data tables

·         SQL injection or Arbitrary code execution

·         Lack of auditing controls


Thus it becomes extremely critical to proactively address the known database security issues by deploying appropriate countermeasures and ensuring confidentiality and integrity of the database including user accounts and stored data.

MySQL is the most popular open-source database and widely popular in Web 2.0 application environments.  MySQL is certainly not my forte! Recently, I had my first experiences with MySQL on couple of projects so I ended up digging deeper into MySQL security and churned up  the features for use in Web 2.0 applications.  Here is my first installment of my hitchhiker’s view on MySQL security and its relevance to Web 2.0 applications.


Securing MySQL database connections


Enforcing confidentiality and integrity of database communications is critical for thwarting eavesdropping and untrusted client connections.  Enabling MySQL connections with SSL/TLS protocol guarantees transport-layer security and assures that the database communciation is not accessible for unauthorized access and the data exchanged is not modified or altered during transit.


To secure communication between the client and the database server,  MySQL supports the use of SSL for ensuring transport-level security using encrypted communication.  Since MySQL 5.0.x, MySQL bundles yaSSL  (compatible with OpenSSL ) to support SSL and related cryptographic requirements.


Configuring MySQL with SSL/TLS communication


If you are using binary versions of MySQL to verify the existence of yaSSL support, login to the mysql client and try the following:


mysql> SHOW VARIABLES LIKE ‘have_ssl’;


| Variable_name | Value  |


| have_ssl      | YES   |




Incase of using MySQL source distribution and if you want to choose OpenSSL  (I strongly recommend OpenSSL as it is FIPS-140 certified) as your SSL provider, you may choose to recompile your MySQL server using  –with-openssl   as configure switches.


# ./configure –with-openssl


To verify the configuration with OpenSSL


mysql> SHOW VARIABLES LIKE ‘have_openssl’;


| Variable_name | Value |


| have_openssl  | YES   |



To establish an SSL communication, you must obtain the SSL certificates from a certificate authority (CA) (recommended) or alternatively you would able generate the certificates using  Solaris Key Management Framework (pktool utility) or OpenSSL (refer my earlier post on OpenSSL as CA/SSL Test Kit: Cheat Sheet) .  To enable SSL, MySQL requires the following three certificate files for both server and client (if required):


a)      CA certificate

b)      Server certificate

c)      Client certificate


You may append the location of these certificate files in the [mysqld] and [client] section of the MySQL server configuration file  my.cnf.  For example:












Alternatively, you can specify each certificate as a command-line argument to mysqld (server) and mysql (client) environments. 


To start the MySQL server daemon with the SSL configuration:







To start the MySQL client to use SSL, assuming the connecting user has no client certificate authentication requirements:


mysql –ssl-ca=cacert.pem


To start the MySQL client, assuming the connecting user is required to provide a client certificate for SSL authentication:








To verify configuration and to ensure that the MySQL server uses SSL connection, the status can be checked from the MySQL client using ssl_cipher status variable.


mysql> SHOW STATUS LIKE ‘ssl_cipher’;


| Variable_name | Value              |


| Ssl_cipher    | DHE-RSA-AES256-SHA |



Test-driving MySQL SSL connections using JDBC

 To test-drive SSL communication using JDBC, MySQL Connector/J  (MySQL JDBC driver) supports using SSL communication as long as the MySQL database server and Java client is configured with SSL certificates. To enable JDBC communication with SSL, it requires setting JDBC property requireSSL=true and useSSL=true.  In case, if you want to validate the Server certificate you may choose to use verifyServerCertificate=true.


Here is the example code, I tried out :


import java.sql.*;

public class TestJDBCoverSSL    {

public static void main(String args[])   {

      Connection mySQLconnection = null;

          try {

                //Register the JDBC driver for MySQL.

                 String url =  “jdbc:mysql://localhost:3306/mysql?&verifyServerCertificate=false&useSSL=true&requireSSL=true”;
                 mySQLconnection =  DriverManager.getConnection(url,  “jdbcuser”, “password”);

                 //Print URL and connection information
                  System.out.println(“URL: ” + url);
                  System.out.println(“Connection: ” + mySQLconnection); 
                 // Close the connection

             }    catch(Exception ex)  {

More importantly, You need to import the SSL certificates in the Java keystore and then provide the Java keystore location properties where the SSL certificates are stored. You may provide these values as -D Java runtime options on the command line as follows:


Alternatively, you may incorporate the Java keystore and truststore properties in the JDBC application:


To summarize, enabling SSL/TLS based MySQL connections ensure trusted communication between MySQL clients and the database server. It helps thwarting attacks related to eavesdropping MySQL communications, Man-in-the-Middle (MITM), Forged requests and so forth.  In my next post, I will discuss how to secure user accounts and enable stronger authentication controls in MySQL.

Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

I always had a love and hate interest with using OpenSSL ! But I should agree that it did help me many times…whenever I wanted to quickly test-drive my craziest ideas with PKI certificates. Couple of things I like about OpenSSL is its tools/utilities for testing as equivalent to a commerecial-grade CA and its FIPS-140 compliance. Also, I always get the required help on Web, right from the details of how-to install, configure…and all the operations. Here is my attempt to share a quick recipe on using OpenSSL commands.. particularly for those looking for help on test-driving SSL certificates using OpenSSL.


(A) Creating RSA Certificates

# openssl  genrsa   2048   >   myRSA-key.pem


This command creates a 2048-bit key pair and stores it in myRSA-key.pem. The default key size is 512 bits. In case if you want to password protect the RSA private key, use the following command:


# openssl genrsa 2048 -aes256 -out myRSA-key.pem


When you run the above command, OpenSSL prompts you for a passphrase for encrypting the key file using an algorithm – ex. AES (aes128, aes192 aes256), DES/3DES (des, des3).


(B) Creating a SSL Server Certificate Signing Request (CSR)

Important Note: This process requires signing by a valid Certificate Authority (CA)


For a commercial deployments, you need to obtain the SSL certificates and associated root CA certificates from a CA (ex. Cybertrust, Entrust, Verisign) . As a first step, you need to create a CSR for requesting the CA to sign (trust) your certificates. The following is the command for creating a CSR.


# openssl req -new rsa:1024 -node -out myCertReq.pem -keyout myPrivCertkey.pem -subj /C=US/ST=MA/L=Burlington/CN=myHost.domain.com/emailAddress=nramesh@sun.com


The generated certificate request (myCertReq.pem) must be signed by a CA otherwise it will not be a valid certificate. The key algorithm is RSA and size 1024 bits, the certificate will be valid for 365 days, and with -nodes option the key will be unencrypted. The -subj allows setting the Subject DN value that identifies the hostname “CN” must be fully qualified name that you’ll be using to access your SSL site.


Save the private key file (myPrivCertKey.pem) as you need the key in order to use the Server certificate from the CA. Just for the reason not to send the private key information to CA. Send the certificate request (myCertReq.pem) to the CA via email or using their web site. After signing process, The CA will return you the signed certificate and also root CA certificates.


(C) Creating the OpenSSL CA certificate


For Intranet or testing purpose, you may want to test with your own CA and it can be done with OpenSSL. Similar to the process (A) , you need to create a private CA key (myCA.key) and then a private CA X.509 certificate (myCACert.pem).


# openssl genrsa 2048 -aes256 -out myCA.key

# openssl req -new -x509 -days 3650 -key myCACert.key -out myCACert.pem


(D) Creating a Self-signed certificate (For SSL)

For your testing purposes, you may want to SSL test your applications with self-signed certificates and with your own CA. To create a self-signed certiicate:


# openssl req -nodes -x509 -newkey rsa:1024 -out mySelfSignedCert.pem -keyout myPrivServerKey.pem -days 365 -set_serial 01-subj “/C=US/ST=MA/L=Burlington/CN=myHost.domain.com/emailAddress=nramesh@sun.com


-x509 identifies it as a self-signed certificate and -set_serial sets the serial number for the server certificate. You may want to remove the password from the private key (so that the SSL server will not prompt you for password). Here is the command:


# openssl rsa -in myPrivServer.key -out myPrivServer.key.insecure


In some cases, you may want to create a single file that contains both private key and the self-signed certificate:


# openssl req -x509 -nodes -days 365 -newkey rsa:1024 -subj”/C=US/ST=MA/L=Burlington/CN=myHost.domain.com/emailAddress=nramesh@sun.com -keyout myServerCert.pem -out myServerCert.pem


To create a SSL certificate signed by your own Certification Authority (CA).


# openssl ca -cert myCACert.pem -in myCertReq.pem -out myServerCert.pem


Where myCACert.pem is the CA certificate, we discussed in (C).


(E) Testing the Certificate with OpenSSL

OpenSSL provides an s_server command that provides a SSL/TLS server implementation to test/verify support SSL/TLS based connections. By default, the s_server listens on port 4433. You should able to test your certificate by running the following command:


# openssl s_server -cert myServerCert.pem -www


The above command should launch an OpenSSL based SSL server using your certificates. To verify SSL connection with your certificates, try accessing https://localhost:4443/ from your browser. You must be seeing a simple web page listing the connection details and all the supported ciphers.


(F) Converting certificates from PEM to PKCS#12 formats

PKCS12 is an RSA standard for creating “Personal Information Exchange Syntax Standard” based certificates commonly used for email signatures (ex. pfx or p12). A PKCS#12 file combines all-in-one file including public key, private key, and the root CA certificate. With OpenSSL, you would able to convert a PEM file to PKCS#12 format file, you would use the following command (all in one line ignore \ ):


# openssl pkcs12 -export -in myServerCert.pem -inkey myPrivateServerKey.pem -certfile myCACert.pem -name “[friendly name - Ramesh Nagappan]” -out myServerPKCS12Cert.pfx


(G) SSL Certificate Pre-requisites for Apache and MySQL

If you are thinking about configuring SSL for your Apache Web Server or MySQL database connections, you would need the following:

1) Create the CA (private key and public cert) certificates.

2) Create your SSL server key.

3) Create your SSL server certificate.

Make sure your Common Name (CN( identifies “full-qualified domain name (FQDN)” of your server. Follow the directions for configuring SSL using Apache and MySQL documentation.

Enjoy. Let me know, if you had any suggestions.

Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

Important Disclaimer:The information presented in this weblog is provided “AS IS” with no warranties, and confers no rights. It solely represents our opinions. This weblog does not represent the thoughts, intentions, plans or strategies of our employers.