Certificates – Digital Certificates (Summary)

Introduction to Digital Certificates

Digital Certificates provide a means of proving your identity in electronic transactions, much like a driver license or a passport does in face-to-face interactions.

With a Digital Certificate, you can assure friends, business associates, and online services that the electronic information they receive from you are authentic.

This document introduces Digital Certificates and answers questions you might have about how Digital Certificates are used for information about the cryptography technologies used in Digital Certificates.

Digital certificates are the equivalent of a driver’s license, a marriage license, or any other form of identity.

The only difference is that a digital certificate is used in conjunction with a public key encryption system. Digital certificates are electronic files that simply work as an online passport.

Digital certificates are issued by a third party known as a Certification Authority such as VeriSign or Thawte.

These third party certificate authorities have the responsibility to confirm the identity of the certificate holder as well as provide assurance to the website visitors that the website is one that is trustworthy and capable of serving them in a trustworthy manner.

Digital certificates have two basic functions.

The first is to certify that the people, the website and the network resources such as servers and routers are reliable sources, in other words, who or what they claim to be.

The second function is to provide protection for the data exchanged from the visitor and the website from tampering or even theft, such as credit card information.

Who Uses Digital Certificates

Digital Certificates can be used for a variety of electronic transactions including e-mail, electronic commerce, groupware and electronic funds transfers.

Netscape’s popular Enterprise Server requires a Digital Certificate for each secure server.

For example, a customer shopping at an electronic mall run by Netscape’s server software requests the Digital Certificate of the server to authenticate the identity of the mall operator and the content provided by the merchant.

Without authenticating the server, the shopper should not trust the operator or merchant with sensitive information like a credit card number.

The Digital Certificate is instrumental in establishing a secure channel for communicating any sensitive information back to the mall operator Virtual malls, electronic banking, and other electronic services are becoming more commonplace, offering the convenience and flexibility of round-the-clock service direct from your home.

However, our concerns about privacy and security might be preventing you from taking advantage of this new medium for your personal business.

Encryption alone is not enough, as it provides no proof of the identity of the sender of the encrypted information. Without special safeguards, you risk being impersonated online.

Digital Certificates address this problem, providing an electronic means of verifying someone’s identity.

Used in conjunction with encryption, Digital Certificates provide a more complete security solution, assuring the identity of all parties involved in a transaction.

Similarly, a secure server must have its own Digital Certificate to assure users that the server is run by the organization it claims to be affiliated with and that the content provided is legitimate.

Types of Digital Certificate:-

  1. Identity Certificates

An Identity Certificate is one that contains a signature verification key combined with sufficient information to identify (hopefully uniquely) the key holder.

This type of certificate is much subtler than might first be imagined and will be considered in more detail later.

  1. Accreditation Certificates

This is a certificate that identifies the key holder as a member of a specified group or organization without necessarily identifying them.

For example, such a certificate could indicate that the key holder is a medical doctor or a lawyer.

In many circumstances, a particular signature is needed to authorize a transaction but the identity of the key holder is not relevant.

For example, pharmacists might need to ensure that medical prescriptions are signed by doctors but they do not need to know the specific identities of the doctors involved.

Here the certificate states in effect that the key holder, whoever they are, has permission to write medical prescriptions’.

Accreditation certificates can also be viewed as authorization (or permission) certificates.

It might be thought that a doctor’s key without identity would undermine the ability to audit the issue of medical prescriptions.

However, while such certificate might not contain key holder identity data, the certificate issuer will know this so such requirements can be met if necessary.

  1. Authorizations and Permission Certificates

In these forms of certificate, the certificate signing authority delegates some form of authority to the key being signed.

For example, a Bank will issue an authorization certificate to its customers saying ‘the key in this certificate can be used to authorize the withdrawal of money from account number 271828’.

In general, the owner of any resource that involves  electronic  access  can  use  an  authorization  certificate  to  control  access  to  it.

Other examples include control of access to secure computing facilities and to World Wide Web pages.

In banking an identity certificate might be used to set up an account but the authorization certificate for the account will not itself contain identity data.

To identify the owner of a certificate a bank will typically look up the link between account numbers and owners in its internal databases.

Placing such information in an authorization certificate is actually undesirable since it could expose the bank or its customers to additional risks.

The Parties to a Digital Certificate

In principle there are three different interests associated with a digital certificate:

  1. The Requesting Party

The  party  who  needs  the  certificate  and  will  offer it  for  use  by  others  –  they  will  generally provide some or all of the information it contains.

  1. The Issuing Party

The  party  that  digitally  signs  the  certificate  after  creating  the  information  in  the  certificate  or checking its correctness.

  1. The Verifying Party (or Parties)

They are Parties that validate the signature on the certificate and then rely on its contents for some purpose.

For example, a person – the requesting party –they might present paper documents  giving proof of identity to a government agency – the issuing party – who will then provide an identity certificate that could then be used by a bank – the verifying party – when the requesting party opens a bank account.

The term ‘relying party’ is sometimes uses instead of ‘verifying party’ but this can be misleading since  the  real  purpose  is  to  identify  a  party  who  checks  the  certificate  before  relying  on  it.

In  a credit card transaction many parties might handle a certificate and hence rely on it in some way but  only  a  few  of  these  might  actually  check  the  validity  of  the  certificate.

Hence  a  ‘verifying party’  is  a  party  that  checks  and  then  relies  on  the  contents  of  a  certificate,  not  just  one  that depends on it without checking its validity.

The actual parties involved in using a certificate will vary depending on the type of certificate.



Certificates – CSR (Certificate Signing Request).

What is a CSR (Certificate Signing Request)?

What is a CSR?

A CSR or Certificate Signing request is a block of encrypted text that is generated on the server that the certificate will be used on.

It contains information that will be included in your certificate such as your organization name, common name (domain name), locality, and country.

It also contains the public key that will be included in your certificate.

A private key is usually created at the same time that you create the CSR.

A certificate authority will use a CSR to create your SSL certificate, but it does not need your private key.

You need to keep your private key secret.

What is a CSR and private key good for if someone else can potentially read your communications?

The certificate created with a particular CSR will only work with the private key that was generated with it.

So if you lose the private key, the certificate will no longer work.

What is contained in a CSR?

Common Name The fully qualified domain name (FQDN) of your server. This must match exactly what you type in your web browser or you will receive a name mismatch error. *.google.com
Organization The legal name of your organization. This should not be abbreviated and should include suffixes such as Inc, Corp, or LLC. Google Inc.
Organizational Unit The division of your organization handling the certificate. Information Technology
IT Department
City/Locality The city where your organization is located. Mountain View
State/County/Region The state/region where your organization is located. This shouldn’t be abbreviated. California
Country The two-letter ISO code for the country where your organization is location. US
Email address An email address used to contact your organization. webmaster@google.com
Public Key The public key that will go into the certificate. The public key is created automatically

What is a CSR’s format?

Most CSRs are created in the Base-64 encoded PEM format.

This format includes the “—–BEGIN CERTIFICATE REQUEST—–” and “—–END CERTIFICATE REQUEST—–” lines at the begining and end of the CSR.

A PEM format CSR can be opened in a text editor and looks like the following example:


How to generate a CSR Certificate using Openssl in Linux ?

openssl req -out <name>.csr -new -newkey rsa:2048 -nodes -keyout privateKey_<name>.key

How do I decode a CSR?

In order to decode a CSR on your own machine using OpenSSL, use the following command:

openssl req -in <name>.csr -noout -text

What is a CSR/Private Key’s bit length?

The bit-length of a CSR and private key pair determine how easily the key can be cracked using brute force methods.

A key size of 512 bits is considered weak and could potentially be broken in a few months or less with enough computing power.

If a private key is broken, all the connections initiated with it would be exposed to whomever had the key.

A bit-length of 1024 is exponentially stronger, however, it is more and more likely to be broken as computing power increases.

The Extended Validation guidelines that SSL certificate providers are required to follow (http://cabforum.org/documents.html), require that all EV certificates use a 2048-bit key size to ensure their security well into the future.

Because of this, most providers encourage 2048-bit keys on all certificates whether they are EV or not.

%d bloggers like this: