Certificate Communications

SSL Certificates
Features of a certificate

An issue with certificates is that they aren't very useful unless they are trusted. Popular web browsers tend to pre-trust certain root authorities. Being such a root authority can be a substantial convenience for end users.

Additional certificate authorities can be added to software. Following are some instructions, for various software, to determine what is in the list of certificates/chains that are trusted.

[#certffx]: Firefox certificates
Go to the Preferences/Options screen. (In Windows, go to Tools, Options. In other operating systems, go to Edit, Preferences.) Then go to Advanced. If there is an “Encryption” tab, select that tab. In a “Certificate”/“Certificates” section, select a “View Certficates” button.
[#certmsie]: MS IE
Go to Internet Options (from the Tools menu, or from the operating system's Control Panel if Internet Options shows up there). On the Content tab, there is a Certificates option with a Certrificates button. Various tabs will show various certfiicates. Or, instead of using the Certertificates button, the “Publishers” button will also open up the Certificates screen but will jump straight to the “Trusted Publishers” section.

Issuing (root) authority

This, combined with the trust chains in the software, ends up determining whether the certificate is trusted.

Who the certificate is issued to
What the certificate is meant to be good for
e.g., an SSL web server, or S/MIME E-Mail
Revocation status

Clients may check a local list of revoked certificates and/or check with the certificate issuer to see if the cert has been revoked.

To view revoked certfiicates:

[#crtrvkie]: MS IE Revoked Certificates
View the certificates in MS IE, and look for a tab called “Untrusted Publishers”.
Certificate Revocation in Firefox
Near the option to view certs in Firefox: Go to the Preferences/Options screen. (In Windows, go to Tools, Options. In other operating systems, go to Edit, Preferences.) Then go to Advanced. If there is an “Encryption” tab, select that tab. In a “Certificate”/“Certificates” section, select a “Revocation Lists” button.
Further details
e.g. what web servers are listed on the certificate, whether the certficate is a wildcard certificate, etc.
Obtaining(/creating) a certificate
Intended use

First, determine what the certificate is going to be used for. Here are some of the broad categories:

  • S/MIME E-Mail
  • A simple certificate for use with a web server that is serving encrypted content
  • A certificate which contains some more advanced security markers, and is intended for a web server that serves encrypted content
  • Other (e.g. creating VPN tunnels: NetGear documentation

Note by Calomel's guide to SSL Certificates: Using “Google Adsense”, Google “Analystics or other non-encrypted data” on a web page will cause a web browser to mix secured and unsecured content. This is a substantial problem as the web browser is likely to show that there is insecure content. So, here is a simple recommendation: Do not bother with SSL Certificates (so, do not bother with trying to support HTTPS) for any web page that will be serving unencrypted content. This is certainly (and possibly especially) true for unencrypted content that comes from third parties. As content by third parties may be less controlled, this might be an issue which leads to a decision to not use HTTPS (or to adjust web content). Note that for Google Analytics specifically, there may be a solution provided by StartSSL FAQ #42.

Choosing a provider

e.g., for internal use, self-signing may be a fine solution. Enterprise organizations may prefer to pay for an expensive certificate from a provider who has an advanced infrastructure to publicly verify large amounts of certificate requests. Other organizations may prefer to use whatever is cheapest and which works okay, possibly preferring to spend a bit extra to look even nicer in a browser (e.g. having a different color in the address bar of Firefox).

[#mkcrtreq]: Creating a Certificate Request

A decision needs to be made about the key type and key size.

Determining the type of certificate
[#certkytp]: Key type

RSA may currently be the most convenient/worthwhile key type to work with. Here are some basic reasons why:

  • RSA may be more convenient in some cases that involve the general public, due to widespread support including popular web browsers
  • As of PuTTYGen 0.65, it appears that PuTTY's latest support consisted of: SSH-2 RSA, SSH-2 DSA, SSH-1 RSA
    • Presumably, OpenSSH recommends using some of the newer keytypes, such as ECDSA. However, PuTTY doesn't seem to support them yet. PuTTY wishlist: ECDSA cites Wikipedia's article on ECC patents. PuTTY update notes “support is implemented” as of the last day of February 2015, but comments indicate that further work should be done “before releasing EC support if possible.”
      • PuTTYGen Development snapshot 2015-08-17.67629cc also added ECDSA and ED25519 (between DSA and “SSH-1 (RSA)”.
    • Of the protocols that PuTTY supports, some of them are losing popularity: OpenSSH 7.0 Release Notes describe reducing support for DSA and SSH version 1.
    • ED25519 page notes, “Ed25519 software is in the public domain.” At the time of this writing, the main drawback is simply that there isn't much widespread support for this relatively new option. However, if this is an option that works (because all parties have software that support this option), then using this may be better than the alternatives mentioned.
    About DSA (a.k.a. DSS)

    OpenSSH 7.0 release notes referred people to the URL of Using OpenSSH with legacy SSH implementations which (at the time of this writing) states,

    OpenSSH 7.0 and greater similarly disables the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use. It can be re-enabled using the HostkeyAlgorithms configuration option:
    ssh -oHostKeyAlgorithms=+ssh-dss user@

    (The text was quoted accurately; HTML including CSS has been altered from the originally quoted HTML.)

    Previously, this guide recommended DSA. That is primarily because OpenBSD 5.2 man page for SSL (section called “BUGS”) has just one issue it notes: “The world needs more DSA capable SSL and SSH services.” Examples in this guide have shown DSA, hoping that those who follow the examples may help the situation noted in OpenBSD 5.2's manual page for SSL. However, OpenSSH.com: Legacy Options says, “OpenSSH 7.0 and greater” ... “disable the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use.” So, recommendations change over time, and the earlier recommendation (which encouraged DSA) is no longer an active recommendation by the same people.

    Based on that text, DSA was considered to be a great choice except for when RSA is needed. For example: web browsers. Web browsers typically favored RSA.


    OpenBSD Manual Page for SSL: “HISTORY” section says, among other historical facts, HTTPS “used by web browsers (in modern incarnations) allows for the use of SSL” and TLS, “which in theory allows for encrypted web transactions without using RSA.  Unfortunately, all the popular web browsers buy their cryptographic code from RSADSI. Predictably, RSADSI would prefer that web browsers used their patented algorithm, and thus their libraries do not implement any non-RSA cipher and keying combination. The result of this was that while the https protocol allowed for many cipher suites that did not require the use of patented algorithms, it was very difficult to use these with the popular commercially available software.”

    An earlier part of the manual page, OpenBSD Manual for SSL: Section about Generating RSA Server Certificates For Web Servers starts out noting, “To support https transactions in” the included web server, “you will need to generate an RSA certificate.”

Key size

Calomel's guide to SSL Certificates says, “The private key sizes for SSL must be either 512, 1024, 2048 or 4096 bits, for compatibility with modern web browsers.” It recommends 4096 for compliance with a specific standard. Forum posting about 4096-bit keys indicates Firefox may support them better than other browsers, and discusses trade-offs to different key sizes.

RSA's guide to key sizes

Certificate contents

Having answers, about what information needs to go into the certificate, will help when the time comes to actually make the certificate. Have this informaiton prepared.

Common Name

This is a fully qualified domain name for the web server, not including a period at the end. e.g.: www.example.com (whichever address the server is for). If a wildcard certificate is being supported, then *.example.com may be speicifed.

It may be, or is, recommended or required to set this to a name of the machine, and not the main domain. StartSSL will notice if just the main domain (e.g. example.com) is used, and prompt to have another name (e.g. www.example.com) provided. The generated certificate will then support both the main domain (e.g. example.com) and the provided common name (e.g. www.example.com).

Organization Name
e.g. what person or organization the certificate is meant for
Organizational Unit Name
This could be used for specifying a specific department of an organization
The name of the city
The standard is to spell this out, with no abbreviations
Country Code
Keep it to two letters.
E-Mail Address
Extra attributes
A challenge password
An optional company name
Creating the files

The method may vary substantially, depending on what software is being used. Please create the file yourself: a file provided by a website could allow an unscrupulous website had a chance to copy the private key file that was used to generate the CSR. Unlike random password generators, the website can view the certificate and have a good idea of what system is using the password, so this would be a sort of open invitation to allow potential compromise.

In order to create a “CSR file” (typically named *.csr when using OpenSSL, or Certreq.txt in IIS), a private key needs to be used. The following instructions will show how to create an appropriate key for this task, in case such a key hasn't already been made. This key should not be given out to anybody (including the certificate signing authority, as that site should have no need for the key).


e.g. used by system that use OpenSSH

Determine the certificate's key type. Then follow the appropriate instructions.

It seems there are a few variations in syntax. Multiple are provided here.

Comodo's documentation: Apache and mod_ssl

Comodo's guide shows some command lines. This looks like it may be the easiest way: just run a command line and generate two files. (At the time of this writing, this way has not been extensively tested by the author of this documentation: instead, following methods from OpenBSD documentation, as described below, have been tested more. So, proceed at your own risk.)

OpenBSD documentation

This section describes creating certificates using commands similar to what is provided by OpenBSD documentation.

[#mkcrtosr]: Server certificates for web servers
Creating the private key (if needed)

Creating a certificate request file will require an existing private key file. (OpenBSD documentation may refer to this as the “server” key. However, the key is fairly specific to the certificate. There is no need for this key to be server-wide unless the certificate is also going to be server-wide, which may or may not be desirable. On a system with just one certificate, this distinction is a moot point. On a system that will use multiple certificates, this distinction adds some clarity on what needs to happen.) So, the first step is to make such a file (using the following instructions) if that file doesn't already exist.

This documentation shows creating files in the current directory. Any directory will do: This documentation creates files in a way that does not require superuser access. Placing the files to an expected location is then shown as a separate step later. (This varies from the documentation provided by the OpenBSD team, which simply creates the files in a default location.) Meanwhile, any sufficiently private location, such as a home directory, may be used as a temporary location for these files.

Generating the key file: newer syntax for making an unencrypted key

OpenBSD Manual for SSL: Section about Generating RSA Server Certificates for Web Servers has commands available. Note: As of OpenBSD 5.0, the commands in this manual page and OpenBSD FAQ 10: Setting up HTTPS were using a superceded syntax. This guide uses a syntax that seems preferred, according to OpenBSD Manual page for the openssl command.

openssl genpkey -algorithm RSA -out ./private.key -pkeyopt rsa_keygen_bits:2048 2>&1 | tee private.mkl

The private.mkl file is simply a log about how the key was made. This is simply being kept for a curiosity, and is in no way needed for this entire process. (Feel free to not keep, or even not create, this file.)

Older syntax (unencrypted key)
openssl genrsa -out ./private.key 2048
Making an encrypted key

The example command lines (both the new syntax and the older syntax), that were just provided, show how to simply create a key which is not password protected. Optional: The key file itself can be protected with encryption. Note that this will require that the password is furnished each time the key needs to be decrypted (which would be each time software loads the key; e.g. each time a web server is started) and automating this may require an accessible copy of the key, which may reduce any gains from going through this hassle.

To make an encrypted file, modify the previous example(s) as described in the following text. (Any key created with the previous examples is unencrypted, and is unneeded if a new encrypted key is going to be used.)

Encrypting with the newer syntax

To perform this optional step, if the command used started with “openssl genpkey ” then add “ -aews-128-cbc -pass stdin” to the end of the command line. Alternatively, instead of “stdin”, there may be some other alternatives described by OpenBSD manual for openssl command: section on Pass Phrase Arguments. The -aes-128-cbc command line parameter looks quite similar to the command provided in OpenBSD manual for openssl command: section about Encoding And Cipher Commands.

Encrypting with the older command line syntax

If the command started with “openssl -genrsa ” or “openssl -gendsa ”, then encryption is done using differnet command line parameters. After specifying the task (e.g. “ genrsa”) for the openssl command to perform, and before specifying “ -out ”, specify a command line that specifies the encryption method, which might be “ -aes256 ” or “ -aes192 ” or “ -aes128 ” or “ -des3 ” or “ -des”.

Making the certificate files

Once the private(“/server”) key is in place, make the certificate request file.

openssl req -new -key ./private.key -out ./server.csr

Understand that this certificate request file is meant to be used to generate a certificate that will work with the server key that was used when making the certificate request. Other server keys cannot be used (as documented by StartSSL FAQ 41: using a new private key.

This command is interactive.

Placing the files in an expected location

At some point, the web server will need to know the location of the private key file. (The *.csr file may not need to go to the same location, although for simple organization, placing the *.csr file in the same protected directory may make sense.) The exact location needed will depend on what is specified by the web server. The private key file may be placed in a desired location now, or after the signed *.crt file is obtained. (When the signed *.crt file is obtained, that file will also need to be placed in a location that is found by the web server.)

More details about desired file placement

(This discussion may not be super necessary if the web server is going to have the file locations configured in a later step. However, the documentation for OpenBSD, the operating system released by the team that releases OpenSSL, places the files in a default location for the web server. So following these instructions now, and other instructions later, could skip this step. Therefore, this discussion is being made to help ensure that this step, the step of placing files where they need to be, doesn't get skipped.)

For a web server that will be using multiple certificates, there may commonly be a unique certificate for each website. In such a case, it may make sense to place the files in a location named after the website, e.g. /etc/ssl/private/siteone/ (or preferably some other name, named after the website's domain, such as /etc/ssl/private/examplec/ if using example.com).

The above example documentation, about creating the needed files, simply show the files being created in a current subdirectory.

Another method, as used by the documentation for OpenBSD (the operating system released by the people who release OpenSSL), shows the files being created directly in an expected destination, so that a default installation of the Apache webserver will find a private key to be used for the entire system. That can certainly be done (and is how the procedure is done by OpenBSD's example documentation: OpenBSD Manual page for the openssl command and OpenBSD FAQ 10: Setting up HTTPS). OpenBSD's documentation shows using a filename of /etc/ssl/private/server.key for the private (“server”) key file. That filename will match the SSLCertificateKeyFile configuration directive for Apache (which may be specified in the default httpd.conf (possibly located in the /var/www/conf/ directory), so using that filename literally (rather than customizing that file's name/path) can save a bit of time.

However, there are two disadvantages to that method. One is that the example documentation doesn't really make it clear that the private key is specific to the certificate. In fact, OpenBSD FAQ 10: Setting up HTTPS refers to it as a “server key”. Both sets of official documentation (the OpenBSD Manual page for the openssl command and OpenBSD FAQ 10: Setting up HTTPS) state, “With /etc/ssl/server.crt and /etc/ssl/private/server.key in place, you should be able to start” the Apache web server with HTTPS support. This verbiage makes it sound like the key is meant for the entire computer system, and possibly that the files are put “in place” in a desired location before the discussion brings up the topic of using the web server.

The second issue with creating the files in the specific location provided is simply that the directory may be privileged, requiring root access to write to. As a result, that method will require root privileges for more tasks than just placing the output files into a restricted directory. In order to minimize the activity that requires superuser privileges, this guide does not use that filename until later in the process. (It is possible, though, for a user with appropriate permissions to start using that filename immediately.)

So, yeah, this method of making files and then placing them may seem less efficient than just making the files directly in their desired locations. A key reason this step was separated was simply to minimize the activity requring superuser access.

If using just one global certificate for the entire system, the following may make sense for a default Apache installation:

sudo cp ./private.key /etc/ssl/private/server.key
sudo cp ./server.csr /etc/ssl/private/server.csr
DSA Server Certificates
OpenBSD Manual for SSL: Section about Generating DSA Server Certificates has some commands available.
Viewing the certs

This may typically be done in web browsers. CAcert Wiki: Placing multiple names in a certificate indicates a method of viewing the data from a signed certificate:

$ openssl x509 -in server.crt -text
Data: Version: 3 (0x2) Serial Number: 63209 (0xf6e9) Signature Algorithm: md5WithRSAEncryption Issuer: O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority/emailAddress=support@cacert.org Validity Not Before: Mar 6 03:06:42 2005 GMT Not After : Mar 6 03:06:42 2007 GMT Subject: CN=www.domain1.com, CN=www.domain2.com

Depends on the version

With at least some version(s) (probably IIS 6?), this can be done in a manner that takes down a website's ability to use an existing certificate. Don't do this on a functional production website that currently has working HTTPS! People have been known to do that when renewing a certificate, and the result is that the website is then unable to use any certificate unless the request is cancelled. Instead, it won't take long to create a “dummy” website that uses the same certificate. Then this extra website can be taken down while a certificate request is being processed. During that time, the functional production site can remain active. Then if the certificate signer takes a long time (hours, even days), the website can still be functioning with the old certificate.

MS KB 228821: Generating a Certificate Request File Using (the Certificate Wizard in) IIS (version 5.0) notes, “This creates a .txt file when you are complete. The default name for the file is Certreq.txt.”


http://www.sslshopper.com/article-how-to-create-a-self-signed-certificate.html says, “reating a self-signed certificate in IIS 7 is much easier to do than in previous versions of IIS. IIS now provides a simple interface for generating a self signed certificate. One drawback, is that the common name of the certificate is always the server name instead of the site name. In order to change the common name, you'll need to follow some additional steps.”

There are numerous guides online, including: Domain.com's guide to creating a CSR with IIS6 GUI.

See: MS KB 228821: Generating a Certificate Request File Using (the Certificate Wizard in) IIS 5.0.

Signing a certificate request

First, a “certificate request” file needs to be made.

OpenBSD Manual for SSL: Section about Generating RSA Server Certificates for Web Servers notes, “You will most likely want to generate a self-signed certificate” ... “along with your certificate signing request”. This is recommended “to test your server's functionality”, “even if you are going to have the certificate signed by another Certificate Authority.” So, start out by self-signing (especially for a new server). Then, after “your Certificate Authority returns the signed certificate to you, you can switch to using the new certificate by replacing the self-signed” certificate file “with the certificate signed by your Certificate Authority”.

Self-signing with OpenSSL
openssl x509 -req -days 366 -in ./server.csr -signkey ./private.key -out ./server.crt

The above was based on OpenBSD FAQ 10: Setting up HTTPS and OpenBSD Manual for SSL: Section about Generating RSA Server Certificates for Web Servers provide an example such as:

openssl x509 -req -days 365 -in /etc/ssl/private/server.csr -signkey /etc/ssl/private/server.key -out /etc/ssl/server.crt

This example involves using a /etc/ssl/private/server.csr created by OpenSSL. This example also involves using a server key, which can be created using making an RSA certificat request file with openssl. (It seems unlikely that is necessary: that any key could be used for signing. However, if the key used to create the *.crt file differs from the key used to create the *.csr file, then it may not be clear which to use with Apache.)

Obtaining a certificate from PKI

Here are some providers:

[#startssl]: StartCom's StartSSL
Home page(s)
http://StartSSL.com, http://cert.startcom.org
Compatible browsers

A list of some logos is shown at the bottom of StartSSL Comparison Chart. More details, about which browsers may come with support for StartCom StartSSL pre-installed, are provided by a forum post about StartSSL support by web clients. Another list may be seen at: Wayback Machine @ Archive.org content of another list (more specifically Wayback Machine @ Archive.org June 2009 content of another list)


Certificates may be viewed/added using: http://www.startssl.com/certs/ (including ca.cer and ca.pem under that directory).

Free cert

Blog about Startcom starting to be supported in Microsoft Internet Explorer states, in bold letters, “StartCom is the only public certification authority providing digital certificates for free!” That statement definitely appeared to be marketing hype, although even marketing hype can be entirely true. (This guide is not making a statement about whether or not the statement is still true. Of course, changes may occur, so the situation described may not end up being the case forever.)

To get a free certificate:

  1. First, know there are limitations.

    • For instance, the certificate is not freely revokable, as noted by StartSSL App 25 FAQ 72: Revoking certificates.
    • The class one (free) certificates are meant for people, not organizations. This is discussed by StartSSL FAQ #2.
    • Wikipedia's article on StartCom (section about StartSSL) states, “In 2012, StartCom began denying requests for the free Class 1 certs when used on commercial websites, and instead requires purchasing a Class 2 (non-free) cert instead.” Unfortunately, the policies seem to only be available in PDF documents. Google Docs viewing of a policy addendum notes, “Class 1 certificates are limited to client and server types”, and a certificates for a server “is restricted in its usage for non-commercial purposes only. Subscribers should upgrade to Class 2 or higher level for any domain and site of commercial user, when using high-profile brands and names or if involved in obtaining or relying sensitive information”. (Perhaps that meant “relaying” sensitive info?)
    • Each generated certificate will only support one server name, as revealed by StartSSL FAQ 38: Using the same certificate on multiple servers. (This is simply a limitation of the free certificates.)
Validation timeframe:
StartSSL #20, Validation details. This “Domain Validation” process basically involves an E-Mail check that is done after logging into the account.


Guide to making a web certificate
Create a certificate request file
Create a certificate request file if this has not yet been done.
Getting to the control panel

Guide to signing up:

Sign up for an account

Use a compatible browser: The Authenticate or Sign-up for StartSSL page notes, “You must enable JavaScript and cookies support at your browser since this site will not work without it.”

Before providing the certificate that will be useful for a web server, a web client certificate will be provided. Prepare to supply information when registering, checking an E-Mail client, installing a web client certificate, exporting that certificate to a file (and creating a password at the time), and saving that exported certificate file and the created password that is needed to make that file useful.

On the Authenticate or Sign-up for StartSSL, choose “Express Lane”. This form notes “Only a natural person can enter into the subscriber agreement during initial registration.” (For organizations, note that Class 1 certificates are not available: they are only available to individuals. StartSSL FAQ #2 states, “an organization name may only appear in a digital certificate at Class 2 level and higher.” Also, for organizations, see Multiple Accounts and Validations.)

In order to sign in, a personal certificate needs to be installed in the web browser. This is a PKCS12 certificate file that is supplied by StartSSL.

Getting the original certificate

Presumably this may be done using Authenticate or Sign-up for StartSSL and then choosing “Express Lane” or “Sign-up”. Sign-Up for free.

After providing the initial sign-up registration information, check the E-Mail account provided. Enter the code into the website to “Complete Registration”, proceed to “Generate Private Key” (which may seem to freeze up for a small number of seconds), and then “Install Certificate”. If the installation was unsuccessful, repeat the entire process so far. Otherwise, export the certificate and then go to the StartSSL: Authenticate or Sign-up page and choose Sign-up.

Exporting the certificate

Prepare to create a password, create a file, and store the password and file safely.

StartSSL FAQ: Backing up a client cert

Importing the certificate

This will require the certificate file, and the password that was used when the certificate file was exported.

Firefox errors when logging in. In Firefox for Windows, choose Tools menu, then Options. For other variations of Firefox, use Edit, then Preferences. Then choose “Advanced”. If there is an “Encryption” tab, choose it. In the “Certificate”/“Certificates” section, choose “View Certificates”. View the first tab, called “Your Certificates”. “Import...”

After importing the certificate, view it. Check its expiration date: These certificates (created by StartSSL) expire after a year.

Perform any needed validations

Check the Validations in the right frame. For instance, the “Email Validations” panel has a green plus sign. Click on it to see what E-Mail addresses have been validated. The green plus sign will turn into a red minus sign when it is showing the E-Mail addresses. The same can be done for “Domain Validations”. These two validation methods are free to perform, and more validations can be added using the “Validations Wizard”.

Creating a “Web Server SSL/TLS Certificate” will require a Domain Validation.

Domain Validation will end up sending an E-Mail to various addresses, which may include postmaster@ and hostmaster@ (or perhaps this came from the SOA record?) and webmaster@ or another E-Mail address (which was a lowercased version of either the Administratrive Contact or Technical Contact from WHOIS details).

Requesting a cert

It is safest to create a CSR file. Skip the section for creating a website. View the CSR file contents and copy them, and paste those contents into the correct field.

The website will report success, stating “All content of the certificate signing request is ignored except its public key.”

Deploying the cert

Note that the key may be encrypted, as noted by StartSSL FAQ 35: How to decrypt the private key and the preceding StartSSL FAQ 34: Why is a password required to start the (Apache) web server?

(After this documentation about StartSSL, and after the documentation about other certification providers, there is a section about deploying the certificate file(s). It may cover more details about deployment.)

On the “Save Certificate” screen, there will be a text box with the desired contents of a ssl.crt file. Copy the files from that text box to a text file. Also, before clicking on the “Finish” button, the bold words (“intermediate” and “root”) are hyperlinks. Use the web browser to save the target of those links.

Follow up
Remember that the personal identification certificate expires.
Unknown/misc notes

(Scratch notes, found in this page...)

Startssl app=33 How to Enroll cert: Provide details. An E-Mail is sent with a code. Supply this code to the web site and the web site will then sign a cert. Somehow the website then gets the cert installed into the web browser (as described by StartSSL FAQ 51: Submitting a certificate request for client certs. The web site will then recommend backing up the cert.

Certificates that require payment

The certifications themselves may not be what requirements payment. Instead, what may require payment is validation that is required by certain types of certificates. This difference in pricing model does not change the fact that the certificates do not get provided until after money is paid. (So, the title of this section is therefore considered to be accurate.)


As clearly stated on StartSSL Fees web page, some certificates require multiple validations and so fees are cumulative. Therefore, the subscript on StartSSL Comparison Chart does mean that getting the “StartSSL Organization Verified” or “StartSSL Extended Validation” will require paying the “StartSSL Identity” Verified/Validation prior to also paying the additional price associated with a higher-end certificate.

Validation requirements
Forum post about Class 2 Validation Requirements, How to Enroll. Submitting a copy of StartSSL's Authorization Letter for Class 2 Organization Validation (PDF file) may be required (submitted either as a modified, filled in PDF file, or scanned/photoed as noted by the “How to Enroll” section).
SSLShopper review notes, “The green-bar for EV SSL Certificates doesn?t currently work.”
Providing certs for others
Multiple Accounts and Validations. Some other information that may be related is: StartSSL Corporate.

Free E-Mail certificates

Positive SSL

Namecheap.com's page about PositiveSSL shows PositiveSSL under the “Comodo Certs” tab, and this page shows a “Comodo”: “Creating Trust Online®” logo.

Calomel.org's guide to Nginx has posted a section called “How to setup a SSL cert from Comodo through NameCheap for Nginx” which says, “For this example we are going to look at Comodo's PositiveSSL though NameCheap which you can get for as little a $1.99 for the first year and $8.95 for the following years.” However, Namecheap.com's page about PositiveSSL seems to be advertising $8.95, without mentioning the $1.99 price. (Perhaps Calomel.org's guide was referring to an old promotion that is no longer valid?)

Positive SSL has a free 30 day trial. Positive SSL may be fairly cheap (e.g. $33.95) compared to Comodo's Instant SSL ($149.80) for Enterprise SSL ($179.80). (Prices obtained from positivessl.com April 20, 2010.)

CAcert Inc.

CACert Disclaimer and License

The certificates are offered by: CACert

used by e.g. SixXS

Ian's Commentary about CAcert's audit, noting “CAcert is formally not seeking access to root lists, partnerships or the like, at the current time.”

The following references seem to refer to another organization: These might be independent references to help locate some lower-priced certificates. (However, this independence is only mentioned as a possibility. This list is not necessarily verified to contain only material by entities that claim to be independent.)

These references may contain some of the same material as each other, as well as some of the same material as this site. They are referenced, though, in case any of them might provide some updated information sooner than this site.

SSLShopper review of free certificates from a free cert authority mentions multiple providers.

Namecheap.com has been known to refer to PositiveSSL.


Wayback Machine @ Archive.org content showing Calomel.org's Nginx guide with GoDaddy info

“Go Daddy” has offered “absolutely free”, “no strings attached” “one-year Standard SSL Certificate” for Open Source projects, which sounds nice for the first year.

Verisign (a.k.a. TheRoot.OfAllEvil.com)

According to Wikipedia's page on Thawte, “In 1999 VeriSign acquired Thawte”. “Both VeriSign and Thawte had certificates in the first Netscape browsers, and were thus 'grandfathered' into all other web browsers. Before VeriSign's purchase, they each had about 50% of the market.”

“The Thawte Web of trust has been discontinued. It was discontinued on 16 November 2009” (as noted by Thawte's FAQ on the End Of Life of the Web Of Trust. Wikipedia's page about Thawte: section called “After End of Life” references a page on the Gossamer Spider Web of Trust site: Thawte EOL

ClickSSL SSL Coupon now redirects to ClickSSL Thawte Promotion code. The website refers to selling Thawte certificates, and the right side of the page has shown references to promotion offers by RapidSSL, GeoTrust, and Verisign.
Others (related to Verisign?)

(related to Verisign?)

http://www.win.tue.nl/hashclash/rogue-ca/#sec71 Was known to use MD5. press release discussed this, and the offer for free re-issuance.
http://www.geocerts.com/ssl/browsers has a section about “How are GeoTrust and Equifax related”.

Netcraft report

GlobalSign SSL

http://forums.oscommerce.com/topic/243127-whats-your-opinion-on-rapidssl/ says RapidSSL is owned by GeoCerts. (But what about RapidSSL being owned by Verisign? Or does Verisign own GeoCerts?)

Other/misc info
Deploying the certificate file(s)

Once the certificate has been obtained, the web server will need to start using this file. Details will be specific to the web server software that is being used. There may be some remaining steps to get the certificate file converted into the needed format. For instance, some certificate signer(s) may provide a Zip file with multiple certificate files. It appears from Calomel.org's guide to Nginx that this could involve concatenating files in a specific required order. So, the first step to getting certificate information in the needed format is to determine just what that format is.

To check for further details on what requirements may exist for various web servers, check out the relevant guide(s) in the section about transfering files with a web server. This may/should have details about setting up HTTPS support. Then, this guide provides more details about some common task(s) associated with handling the *.crt file(s). However, some steps may not be necessary, so the first step (before following any of these other steps) is to identify the desired result, in order to identify which other steps are required.

Some common formats for the certificate files include the *.pem PEM file and a DER *.der DER file. Those formats are quite similar: Apache documentation about converting from PEM to DER notes that the PEM format used “is simply Base64 encoded DER, with header and footer lines.”

Converting between common formats

SSLShopper guide to converting certicate formats provides resources, including several command lines to run when using the openssl command.

From PEM to DER

Apache documentation about converting from PEM to DER notes that this conversion may be done with:

openssl x509 -in cert.per -out cert.der -outform DER

Backing up a cert: see: https://www.startssl.com/?app=25#4 This involves saving a password.

TechNet ...

MS IE: http://support.microsoft.com/kb/297681 MS KB article: 297681 - Error Message: This Security Certificate Was Issued by a Company that You Have Not Chosen to Trust

http://serverfault.com/questions/9708/what-is-a-pem-file-and-how-does-it-differ-from-other-openssl-generated-key-file says that .pkcs12 and .pfx and .p12 files can be split into public and private keys. Files: PEM: RFC 1422: Privacy Enhancement for INternet Electronic Mail: Part II: Certificate-Based Key Management (now marked as historic, perhaps due to RFC 4450: “Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents”?), http://serverfault.com/questions/9708/what-is-a-pem-file-and-how-does-it-differ-from-other-openssl-generated-key-file , RFC 4366: “Transport Layer Security (TLS) Extensions”, Section 3.1: “Server Name Indication” (“SNI”) , http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI Subject Alternate Names (SAN) / UCC