Tag: FIPS-140

Hardware Security Module (HSM) plays a critical role in securing the storage of private keys and accelerating compute-intensive cryptographic processes associated with public-key encryption, symmetric-key(secret-key) encryption and digital signature applications. Using HSM in Oracle Transparent Data Encryption applications will ensure that the Key material stored on the card is protected and not exportable (never leaves the card) and all associated cryptographic operations are performed on the card. Using HSM in payment card transactions is critical and it is mandatory for compliance with Payment Card Industry – Data Security Standard (PCI-DSS), Payment Application – Data Security Standard (PA-DSS) and Health Insurance Portability and Accountability Act (HIPAA) privacy and security requirements and several government security standards.



Oracle Transparent Data Encryption


Oracle Transparent Data Encryption (TDE) was first introduced in Oracle Database 10gR2 as part of the Oracle Advanced Security option. TDE performs encryption and decryption of application table columns or entire application tablespaces. TDE uses standard algorithms and facilitates a built-in key management services for supporting data encryption. Since Oracle Database 11gR1, TDE supports HSMs using PKCS#11 interface to support providing centralized key management and to secure TDE’s master encryption key.




Sun Cryptographic Accelerator 6000 (SCA-6000)



The Sun Crypto Accelerator 6000 is a PCI-E card that combines a cryptographic accelerator for Secure Sockets Layer (SSL) and IPSec sessions and also it can act as a local HSM for performing secure key management functions. Qualified as a FIPS 140-2 Level 3 compliant device, the SCA-6000 PCI-E card is designed to prevent the disclosure or corruption of cryptographic keys, results, or other sensitive data. SCA-600o supports both Solaris and Linux environments.



Applied Scenarios


  • HSM based Secure key store and Master Key Management for supporting encryption and decryption of keys performing actual data encryption:
    1. Encryption/decryption of tablespace keys and table keys
    2. Encryption/decryption support for Oracle Data Pump utility
    3. Encryption/decryption support for Oracle Recovery Manager (RMAN)
    4. Master key backup and recovery
  • FIPS-140-2 Level 3 compliance
  • Acceleration of Network encryption -  SSL/TLS communication between the Oracle client and server.
    • Offloading computationally intensive cryptographic operations to the accelerator

The Role of SCA-6000 as a HSM for Oracle TDE




If you are curious to know the configuration details and ready to test-drive the solution using Sun Crypto Accelerator 6000 (SCA-6000) PCIe card for Oracle TDE – Please download and read the following whitepaper (available from Sun Wiki).





Don’t forget to post your comments.

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

FIPS-140* compliance has gained overwhelming attention these days and it has become a mandatory requirement for several security sensitive applications (mostly in Government and Security solutions and recently with select finance industry solutions and particularly for achieving compliance with regulatory mandates such as PCI DSS, FISMA, HIPPA, etc ). FIPS-140 also helps defining security requirements for supporting integration with cryptographic hardware and software tokens.  Ensuring FIPS compliance to Java based application security has been one of demanding needs of security enthusiasts but unfortunately neither Sun JCE or JSSE is not yet FIPS-140 certified – hopefully soon !  Sun JDK 6 (and above) has also introduced several enhancements including support for enabling FIPS-140 compliance for Sun JSSE using FIPS-140 certified cryptographic providers for supporting SSL/TLS communication and associated cryptographic operations. To accomplish this, Java 6 uses the PKCS#11 support for JSSE to integrate with PKCS#11 based FIPS-140 cryptographic token.

 

Lately I worked on a security solution using SunJSSE with NSS as a software cryptographic token… and here is my tipsheet for those keen on playing FIPS conformance with SunJSSE.

 

  • SunJSSE can be configured to run on FIPS-140 compliant mode as long as it uses a FIPS-140 certified cryptographic hardware or software provider that implements all cryptographic algorithms required by JSSE  (ex. Network Security Services – NSS, Sun Cryptographic Accelerator 6000, nCipher, etc).

 

  • To enable FIPS mode, edit the file ${java.home}/lib/security/java.security and modify the line that lists com.sun.net.ssl.internal.ssl.Provider and associate the name of the FIPS-140 cryptographic provider (ex. SunPKCS11-NSS). The name of the provider is a string that concatenates the prefix SunPKCS11- with the name of the specified PKCS#11 provider in its configuration file.

                            security.provider.4=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS

 

  • In case of using NSS as cryptographic software token (Make use of NSS 3.1.1. or above), assuming the libraries are located under the /opt/nss/lib directory and its key database files  (with the suffix .db) are under the /opt/nss/fipsdb directory, the sample configuration for representing NSS will be as follows:
                           # Use NSS as a FIPS-140 compliant cryptographic token 
                           # SunPKCS11-NSS
                          name = NSS
                          nssLibraryDirectory = /opt/nss/lib
                          nssSecmodDirectory = /opt/nss/fipsdb
                          nssModule = fips
  • In FIPS mode, SunJSSE will perform SSL/TLS 1.0 based communication and cryptographic operations including symmetric and asymmetric encryption, signature generation and verification, message digests and message authentication codes, key generation and key derivation, random number generation, etc.
  • To refer to the SunJSSE supported Ciphersuites suites refer to the Sun JSSE’s documentation and notes for FIPS guidance.

 

* FIPS-140 is a US Federal data security standard approved by the National Institute of Standards and Technology (NIST) – The current version is FIPS-140-2. All US government agencies are mandated to use only FIPS-conformant/validated products for deploying security sensitive applications and solutions.
Onlinerel Facebook Twitter Myspace Friendfeed Technorati del.icio.us Digg Google Yahoo Buzz StumbleUpon

It’s been so long, I had been involved with multiple Smartcard/PKI projects particularly supporting integration of Sun technologies for use with National eID, US Federal (HSPD-12 / PIV cards) and DoD CAC projects. There is no secret sauce,  but unfortunately I did’nt find time to put together a trustworthy documentation addressing the technical aspects of using Smartcard based PKI credentials for Physical and logical access control solution.  Couple of my friends at SIs (too big to name here) involved with large-scale PIV/CAC deployment repeatedly asked me to draft a cheatsheet for them – finally I had some time to put together an unofficial document that illustrates the pre-requisites, architecture scenarios, configuration and deployment of Smartcard based PKI certificate authentication using Sun OpenSSO Enterprise (Formerly referred to as Sun Java System Access Manager). Here is the main feature of the story:

Smartcard/PKI authentication based SSO

OpenSSO supports the use of PKI certificates from Browser or Smartcard/Token based PKI credentials for authentication and enabling Web Single sign-on (SSO) by determining the revocation status of the certificate through the use of the Online Certificate Status Protocol (OCSP), Certificate Revocation Lists (CRLs) and matching the certificate to a pre-existing certificate entry in LDAP.

Tools of the Trade

  1. Sun OpenSSO Enterprise 8 or above
  2. Sun GlassFish Enterprise v2.1 or Sun Web Server 7.0 (or above)
    • Must be configured with an NSS Keystore or FIPS-140 conformant Keystore.
    • PKCS#11/HSM based Keystore (optional)
      • Sun Cryptographic Accelerator (SCA-6000) or another HSM.
  3. Sun Java System Directory Server EE6 or Sun OpenDS (Bundled with OpenSSO )
    • Repository for user accounts and its corresponding PKI certificate entries (optional).
  4. PKI Provider
    • Certificate and Validation Authority
      • Certificate Authority: Cybertrust / Entrust / Microsoft / Verisign
      • OCSP Responders: Tumbleweed / Corestreet OCSP Validator
    • Root CA Certificates and CRLs
      • FBCA SSP CA certificates and CRLs (For PIV/FIPS-201 cards)
      • DoD CA/ECA Root certificates and CRLs (For CAC cards)
      • Govt PKI Root CA certificates and CRLs (For eID cards)
      • OCSP Signing certificate (if required)
  5. Smartcard Reader and drivers
  6. Smartcard client middleware – Browser Plug-in (PKCS#11 or MS-CAPI)
    • ActivIdentity (ActivClient PKI 6.0 / CAC 6.0 or above)
    • GemAlto (GemSAFE)
    • OpenSC PKCS#11 (OpenSC.org) / MUSCLE
  7. Web browser installed with user certificates (Non-Smartcard Scenario)
  8. Smartcards provisioned with PKI certificates
    • PIV, CAC, National eID (PKCS#15/Java Cards)

Architectural Strategies

OCSP based Certificate Validation

In this strategy, OpenSSO determines the revocation status of the certificate by issuing a real-time status request and confirms the status by accepting the response from the OCSP responder. OpenSSO 8 supports OCSP based certificate validation by sending OCSP request validation to an OCSP responder URL (Validation authority or CA) specified in the PKI certificate credential (On the Smartcard) – usually available as an Authority Information Access (AIA) extension attribute (RFC3280). If the AIA attribute is not present, OpenSSO will send the OCSP request to designated OCSP responder URL specified in the OpenSSO Certificate Module configuration.

Logical Architecture - OCSP based Validation Strategy

Logical Architecture - OCSP based Validation Strategy

OpenSSO 8 supports issuing signed OCSP requests by making use of OCSP signing certificates stored in the Web container’s NSS keystore or HSM.

Matching PKI certificates in LDAP/CRLs Repository

In this strategy, OpenSSO determines the validity of the PKI certificate by matching the user’s public-key certificate against the user’s LDAP account  stored in a local or remote LDAP repository. OpenSSO uses the X.509 attributes from the certificate (ex. SubjectDN attributes including uid, emailAddress, serialNumber etc) for searching and retrieving the stored user’s certificate from LDAP.  If the user’s certificate matches the retrieved certificate – the authentication is considered successful.  As a pre-requisite, the cardholder’s public-key certificate from the Smartcard must be obtained out and then stored as an userCertificate;binary attribute entry of the user account in LDAP.

Logical Architecture - Matching to LDAP/CRL entries

Logical Architecture - Matching to LDAP/CRL entries

OpenSSO also supports matching certificates to CRLs in an LDAP repository.  This means OpenSSO uses the Issuer’s DN attribute for searching CRLs in LDAP repository. If the certificate is identified on the CRL; the user authentication is denied. As a pre-requisite, the CRLs must be imported into the LDAP directory. If the user’s certificate includes a CRLDistributionPointsExtension or IssuingDistributionPointExtension   attribute that identifies the location of CRL distribution points where the CRLs are available, OpenSSO certificate module automatically updates it.
In a real-world scenario,  OCSP based certificate validation is overwhelmingly preferred as a best practice over matching certificates using LDAP or CRLs as they require caching them locally, frequency of updates and concerns related to timestamps, authenticity and integrity.

Now, you got the highlights,  if you are ready to dig deeper and test-drive the Configuration and Deployment – Here is the unofficial/unedited cookbook...to make it work. Enjoy and let me know, if you had any suggestions.

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

I had been involved with multiple Biometric ISV providers and its integration with Sun technologies particularly OpenSSO, IdM, Sun Rays and Solaris. I also had the opportunity to deploy Biometric solutions to few govt organizations that starts with “D” and “N”. Believe it or not…we have few of them in production.

Now, getting down to the specifics – Putting it all together, in simpler terms you will see the solution would look like this…..

Ofcourse the Desktop can be your PC or Sun Ray or anything that capable of running a browser and allows plugin a Biometric Fingerprint Scanner (USB device). If you look into the ingredients of this solution, you would need the following:

  1. OpenSSO Enterprise 8
  2. Glassfish V2 Enterprise (Configured to use NSS for FIPS mode)
  3. BiObex Middleware (Biometric enrollment and authentication provider)
  4. SecuGen Hamster IV (FIPS-201) or Hamster Plus Fingerprint Scanners.
  5. BiometricLoginModule (Currently made available through BiObex).
  6. OpenSSO policy agent (based on your target web container) to help enforce authentication on your protected resources.

Here is my quick presentation that digs deeper into the architecture and deployment steps for enabling Biometric SSO using OpenSSO and BiObex.

For those curious to know ….and concerned about security of using Biometrics as a network credential…here is my answer to those known security issues.

  1. The communication, callbacks and biometric samples acquired from the device (In transit to the JAAS LoginModule and then to Biometric authentication provider)  has been cryptographically protected ensuring a trusted path with both transport and message-level security (as per FIPS-140 requirements). This ensures end-to-end confidentiality and integrity of the messages/communication and thwarts image capture, rogue injection and replay attacks.
  2. The user session is verified for proof-of-origin that includes host verification and validation for known IPs and hostnames.
  3. The deployment requires authentication chain with username/password or Certificate authentication (ex. Smartcard PKI) modules to ensure Biometric authentication is used as a second or third factor of the authentication.
  4. OpenSSO callbacks prompt for random fingerprints as enrolled in BiObex.

OpenSSO and BiObex

Multi-factor Authentication Chain : OpenSSO and BiObex



Understanding Biometric SSO


Biometric SSO allows users to access multiple applications (for example, Java EE or Web portal applications) after doing a single biometric authentication. In this case, the biometric authentication is managed by the identity provider infrastructure (ex. OpenSSO) that provides single sign-on services to support participating applications (protected resources). The identity provider encapsulates and protects access by making use of pluggable authentication modules (including a JAAS LoginModule for the Biometric authentication provider) from authentication providers. Upon authentication, the identity provider issues an SSO token that is trusted by all participating applications. This means the identity provider grants or denies access to the secured application or resource by issuing an SSO token that represents the user’s sign-on and session information. All participating applications trust the SSO token issued by the identity provider and grant the caller request to proceed for further processing based on the policies and privileges.

OpenSSO provides JAAS based authentication framework for plugging in JAAS LoginModules (from authentication providers) and also allows enabling multi-factor authentication through OpenSSO authentication chaining and session upgrade features. Refer to OpenSSO Administrator guide for the finer details.

Few weeks ago, I posted another entry on Match-to-Smartcard PKI and Biometric authentication which is a different solution that makes use of Biometric information (CBEFF) stored on a PIV card. I am still working on the documentation….will keep you posted very soon.

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

Last week, I was test driving a PIV Smartcard based PKI as a keystore (via Java PKCS#11)  to support using the PKI/certificate credentials for performing encryption/decryption and digital signature operations  (PKI based logins to Web applications, Encryption/decryption of documents, Digitally signing email). There is no secret receipe but some of you may find it a bit difficult – if you are doing it for first time.  So, here is my quick cheat sheet for your better understanding :

Since J2SE 5.0,  JCE introduced support for the PKCS#11 standard that allows the following:

  • Using hardware cryptographic accelerators for enhancing performance of cryptographic operations.
  • Using smart cards as key stores for key and trust management.

To use these services, it is necessary to install the PKCS#11 implementation provided by the hardware accelerator and smart card vendors. As part of the J2SE 5.0 bundle (and up), Sun facilitates a SunPKCS#11 provider.

To use a smart card as a keystore or trust store, set the javax.net.ssl.keyStoreType and javax.net.ssl.trustStoreType of the Java runtime system properties  to “pkcs11“, and set the javax.net.ssl.keyStore and javax.net.ssl.trustStore system properties to NONE. To specify the use of a vendor smart-card provider, use the javax.net.ssl.keyStoreProvider and javax.net.ssl.trustStoreProvider
Java runtime system properties to identify them. (For example: “SunPKCS11-smart card”). By setting these properties, you can configure an application to use a smart-card keystore with no changes to the application that previously accessed a file-based keystore.

Configuring a Smart card as a Java Keystore (using OpenSC Framework)

OpenSCThe following example shows how to configure OpenSC supported smart card as a Java keystore and list the certificates using the keytool utility. The OpenSC framework can be downloaded from http://www.opensc.org.

  1. Add the OpenSC PKCS#11 module as the keystore provider in java.security file located at $JAVA_HOME/jre/lib/security/java.security.

    security.provider.1=sun.security.pkcs11.SunPKCS11   /opt/openSC/openscpkcs11-solaris.cfg

  2. Create the OpenSC PKCS#11 configuration file. For example, the openscpkcs11-solaris.cfg looks like as follows:
    name = OpenSC-PKCS11
    description = SunPKCS11 w/ OpenSC Smart card Framework
    library = /usr/lib/pkcs11/opensc-pkcs11.so
  3. With the above settings, it is possible to use the smart card as a keystore and retrieve information about the certificates from your Smartcard. For example,  you may use the keytool utility to list certificate entries from a smart card:

$ keytool -keystore NONE -storetype PKCS11 -providerName SunPKCS11-OpenSC -list -v
Enter keystore password: <SMARTCARD_PIN>
Keystore type: PKCS11
Keystore provider: SunPKCS11-OpenSC
Your keystore contains 4 entries

Alias name: Signature
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Owner: SERIALNUMBER=79797900036, GIVENNAME=Nagappan Expire1779,
SURNAME=R, CN=Nagappan (Signature), C=US
Issuer: CN=Nagappan OpenSSL CA, C=US
Serial number: 1000000000102fdf39941
Valid from: Sat Nov 01 15:29:22 EST 2008 until: Wed Jun 01 15:29:22 EST 2009
Certificate fingerprints:
MD5: 12:20:AC:2F:F2:F5:5E:91:0A:53:7A:4B:8A:F7:39:4F
SHA1:
77:76:48:DA:EC:5E:9C:26:A2:63:A9:EC:A0:14:42:BF:90:53:0F:BC
Alias name: Root
Entry type: trustedCertEntry
Owner: CN=Nagappan OpenSSL Root CA, C=US
Issuer: CN=Nagappan OpenSSL Root CA, C=US

Serial number: 11111111111111111111111111111112
Valid from: Sat Nov 01 15:29:22 EST 2008 until: Wed Jun 01 15:29:22 EST 2009
Certificate fingerprints:
MD5: 5A:0F:FD:DB:4F:FC:37:D4:CD:95:17:D5:04:01:6E:73
SHA1:
6A:5F:FD:25:7E:85:DC:60:81:82:8D:D1:69:AA:30:4E:7E:37:DD:3B
Alias name: Authentication
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Owner: SERIALNUMBER=79797900036, GIVENNAME=Nagappan Expire1779,
SURNAME=R, CN=NAGAPPAN, C=US
Issuer: CN=Nagappan OpenSSL CA, C=US
Serial number: 1000000000102fd10d2d9
Valid from: Sat Nov 01 15:29:22 EST 2008 until: Wed Jun 01 15:29:22 EST 2009
Certificate fingerprints:
MD5: 29:7E:8A:5C:91:34:9B:05:52:21:4E:49:5B:45:F8:C4
SHA1:
15:B7:EA:27:E1:0E:9D:94:4E:7B:3B:79:00:48:A2:31:7E:9D:72:1A

—————–

Using Sun Ray DTU as your Smart card Reader

In our case, the customer chose to use Sun Ray as the Smartcard reader where the inserted card is used for performing session mobility and PKI/Certificate based cryptographic operations. To enable access to Smartcard based PKI credentials on Sun Rays, make sure you install the Sun Ray PC/SC Lite to support accessing smart cards. You may download the PC/SC Lite for Sun Ray Server (SRSS 4.x) from:

http://www.sun.com/download/products.xml?id=46af59b2

Enjoy

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