Create a certificate

In this procedure you create a Certificate Signing Request (CSR) certificate.

To secure your web server and applications to use the SSL/TLS protocol, you must send a Certificate Signing Request to one of the trusted Certificate Authority companies on the Internet that will provide you with a certificate you can trust.

The CSR must be created on the server where the certificate is intended to be deployed. You use the openssl tool to create the CSR. In addition to creating the CSR, you may want to create a self-signed certificate for testing purposes. To do so, follow the steps after creating the CSR.

  1. Create a Certificate Signing Request and private key:
    $ openssl req -new -out MyCert.csr
    Follow the instructions to create the CSR. This command creates a pem file containing the private key of the CSR. The key is encrypted, so you are prompted for a passphrase for it. You will be prompted to identify the subject or issuer of the certificate in a series of prompts. These are examples of what the prompts will look like:
    Country Name (2 letter code) [AU]:FR
    State or Province Name (full name) [Some-State]:.
    Locality Name (eg, city) []:.
    Organization Name (eg, company) [Internet Widgits Pty Ltd]:.                               
    Organizational Unit Name (eg, section) []:.
    Common Name (e.g. server FQDN or YOUR name) []:
    Email Address []:.
    The Common Name (CN) will need to be defined according to the purpose of the certificate:
    • As the server certificate:

      If the certificate is intended as the server’s proof of identify so clients can authenticate the server, the CN must match the domain name of the server (DNS); otherwise, clients will not trust its identity and the communication is stopped. For instance, if the URL of the server is https://www.MyServer.com/fastcgi/ws/r/MyWebService, the CN must be www.MyServer.com.

      Tip: Make sure all hostnames are included

      The subjectAltName parameter may be used for variations of the domain and sub-domain names the certificate is intended to protect, such as MyServer.com, mail.MyServer.com, and so on. Also, the IP address may be added in the SubjectAltName as an alternative name for the name defined in the CN. For more information on Subject Alternative Names, go to OpenSSL (external link).

    • As the client certificate:

      If the certificate is intended as the client’s proof of identify on the server side, it is not necessary to match the CN with the client’s DNS as long as the issuer of the certificate is one of the trusted CAs sent by the server. Therefore, the CN field can be left open.

    In the other fields, you provide additional details about your organization, which may be needed if you are purchasing an SSL certificate from a certificate authority.
    Two files are created, MyCert.csr and a private key file called privkey.pem.
    Note: About the CSR and its private key:
    • If you want an official Certificate Authority, you must send the CSR file to one of the self-established Certificate Authority companies on the Internet instead of creating it with openssl. See Encryption and authentication.
    • The CSR file is also used to encrypt messages that only its corresponding private key can decrypt.

Create a self-signed certificate

If you need to create a self-signed X.509 certificate for testing purposes, perform the following steps:

  1. Remove the private key password (Optional):
    $ openssl rsa -in privkey.pem -out MyCert.pem

    The unprotected private key is output in MyCert.pem.

  2. Create a certificate from the CSR signed by the certificate created in Create a root certificate authority:
    (line breaks added for document readability)
    $ openssl x509 -in MyCert.csr -out MyCert.crt -req 
       -CA MyRootCA.crt -CAkey MyRootCA.pem -days 365
    The certificate is output in MyCert.crt.
What to do next.

Once you have a certificate, either issued and signed by a trusted Certificate Authority (CA) or self signed for testing, you need to configure it according to its intended use:

  • As a server certificate:

    The server’s certificate and key must be configured in the web server (for example, IIS, Apache, and so on). For an example, go to Configuring the Apache web server for HTTPS

  • As a client certificate:
    The client certificate and key need to be configured according to their use for either web services or web applications:
    • For use with web service, you configure entries in the FGLPROFILE file. For details, go to Set FGLPROFILE entries for the client certificate
    • For use with web application using HTTPS, you need to install the certificate in the browser or in the keystore/keychain of the operating system.
    You also need to declare the server's Certificate Authority List according to its use for either web services or web applications: