1. Certificate Request Generation using WebCert

If you already have a certificate request file (often identified with a .csr extension), you can skip to 2.

new certificate data entry

In order to generate a new certificate, we need to create a certificate signing request (CSR). The request will carry the name and possibly other details of its future owner. Using Create CSR from the top menu bar will call buildrequest.cgi, and the necessary form will be displayed. At a minimum, the Common Name (CN) of the future certificate must be provided there. You can also select the key type and size, or accept the displayed values as a standard.

2. External Certificate Generation

webcert request paste

If you already have a certificate request, say its already generated for you by a smart network or firewall device (i.e. Cisco, Netscreen), you already got a key pair that stays in the system. Here you simply cut and paste the certificate request into the certrequest.cgi form using the Verify CSR menu item, and generate the certificate. Once done, simply import the certificate into your device.

A valid certificate request looks like this (example):


You need to paste such a request, including the "Begin" and "End" lines, into the certrequest.cgi form and press [verify].

3. Certificate Request Verification

new certificate key and extensions

After a external certificate request has been pasted into WebCert, or WebCerts certificate building form has been used, a verification will show you the certificate information that will be signed.

Here, several additional certificate extensions can be set such as the key usage, defining the type of the certificate. The extended key usage option can be be added to certificates who *really* need it. Please enable this option only if you are sure this is needed. For example, server certificates used with Microsoft Windows to enable the Active Directory ldaps:// function need the addition of the "SSL/TLS Web Server Authentication" extended key usage setting.

Note: An externally generated certificate request, that is pasted into Webcert could already carry certificate extensions. In that case, WebCert uses their requested values and does not provide the option to override that data.

Next, we need to define the start and end date the certificate should become valid for. The default selection will set it to become valid immediately, with a expiration date of 3 years. The expiration date can be changed, or specific time frames can be set to precisely define the time period.

Important: If Webcert was used to create the certificate request together with the key, we need to save the private key which is displayed only here. For security reasons, no other copy is kept on the server. Simply copy&paste the displayed PEM key data into a local text file.

4. Certificate Signing

Finally, we use Sign Request to generate the certificate, singing it with WebCerts root CA certificate. If the process is successful, you'll get a certificate displayed that looks like this:


new certificate generated

Now you can cut and paste it via an editor such as Windows Notepad into a text file and save it locally. Alternatively, you can use the Export functions to download the certificate as a file.
A detailed description for generating a S/Mime certificate to enable e-mail encryption is here: http://fm4dd.com/howto/openssl/webcert-smime-howto.htm

5. Certificate Export

Certificates can be exported for easy download in either DER, PEM or PKCS12 format. When requested for the first time, the selected format is written to the /export directory on the WebCert server, and a download link is provided to save the file locally.

To create a PKCS12 container for easy use with Windows S/MIME you will need the previously generated private key in PEM format for pasting it into the export form. The PKCS12 container will be secured with the supplied passphrase in the export form. This passphrase is needed when the .p12 file is imported by Windows.

6. Certificate Installation

Certificates can be installed/loaded from the cut&paste text files or from the downloaded certificate files which were exported. For some applications, the filename must have a certain extension such as [certfile].pem for PEM files - try to rename it if that is the case. Sometimes it is also necessary to co-install the CA Root certificate to enable the verification of the generated certificate. WebCerts singing Root CA certificate is available for download through the Root CA Cert menu item.

7. Certificate Management

webcert certificate store

All certificates are stored in the /cert directory on the WebCert server. They can be viewed with the List Certs menu option. WebCert conveniently displays the certificate subject, along with the remaining time each certificate is valid.

The Detail button displays the certificate data including its PEM format, convenient for importing it into various certificate stores. The Renew button creates a new CSR from the existing certificate data for simple renewal.

8. Certificate Search

webcert certificate search

To find a particular certificate, the Search Cert menu option brings up a selection of filters that will extract the applicable certs from the cert store per subject field, serial number, validation or expiration date. For example, this helps to identify certificates that are about to expire, and let us renew them before they become invalid.

9. Certificate Validation

webcert certificate validation

The Verify Certs menu option is a powerful way to identify issues around certificates. A crucial part of using certificates lies in the validation through a chain of "signing" certificates. With this function, the chain can be constructed and verified, similar to the way applications, such as a web browser would do. This works with all certificates, not just the ones created with WebCert.

This function can upload local certificate files, or it can connect directly to a remote SSL server and extract the certificate data from there. It is very convenient to verify if a servers SSL setup is correct.

10. Common Errors

Not including the "Begin" or "End" lines, or having an additional empty line before or after the "Begin" or "End" lines when pasting the request into the form will result in a "Error invalid request format, no BEGIN/END lines".

Accidentially hitting [return] somewhere in the paste window, generating a newline in the request data, will result in a "Error cant read request content with PEM function".

In short, CAREFULLY pasting the request resolves most errors.

Trying to generate a certificate from a request that has been already processed works just fine.

11. Browser Complaints

Browser constantly asks if this certificate can be trusted and complains about various things:

Importing the Root CA "parent" certificate can help resolve this issue. Thats what the "Get Root CA cert" is for. Loading the Root CA into your browser enables the automatic verification of the certificate every time you connect. No questions asked.

If there is still the window popping up asking if you want to accept this certificate, then its mostly a missmatch between the certificate common name (CN) and the device name/server name/device IP/server IP. Either the certificate was requested wrongly, or the device changed its name/IP recently. Ask the device owner to generate a new certificate (request) with the valid device name/IP entry.

Certificates are signed to be valid for a time range and "expire". The expiration defaults to 3 years. This should give plenty of time to regenerate a new certificate when the time comes. Certificates still can work when when expired, but the browser comes up with and error message. Re- certification of devices is a good way to enforce inventory updates.

OpenSSL on 32-bit systems may encounter the year-2038 bug. WebCert can restrict the certificate generation prior to the critical date.

11. Links

last update 1/11/2016 @2003-2016 Frank4DD

OpenSSL Logo


OpenSSL Documentation