Header Ads

Types of Certificates


1.CER – A file type for a Certificate. This is microsofts implementation where as a CRT is commonly used in Unix or Linux. However, MS will import CRTs just by changing their extentions to CER. This is also known as an x.509 certificate

2.DER - An encoding for a certificate that is not readable. This is a type of encoding for a CER File.

3.PEM – A base64 encoding for a certificate that is readable. This type is what most of you are used to seeing in CSR files where it begins with -------Begin-------- (Note these files can be manually merged to create certificate chains. See the Java Keystore Renewal document for more information.)

4.P7B – This is a Certificate that includes all Chain Certificates. This is also known as a PKCS #7 Cert.

5.Key – This is the encryption key that is bound to the Certificate that has been signed. Keys can be encoded with Der or Pem encodings. This is also known as a PKCS #8 Key.

6.PFX – This is a certificate that includes the Key that is bound to it for encryption purposes. This certificate can include all Chain Certificates, if you choose to do so, which is a best practice. This file type is required when utilizing load balanced servers. This is also known as a PKCS #12.

7.SAN – Subject Alternative Name certificates are standard certificates where there is an additional Field added to the certificate to make it valid under other DNS names. For instances, ask.ey.net could also be valid for ask-Mobile.ey.net, USSECVMASKWEB1, UCSSECVMASKWEB1.ey.net, or even the IP Address. This keeps you from getting errors when accessing the site via these alternate methods. There is no max number of DNS entries, the field has a 4KB max, so the max depends on how long your names are. But under 100, you should be fine.

8.Internal Certificates – Internal certificates are certs that are signed by our Enterprise AD Level 3 team. These are housed within the EY Internal Certificate servers. These cert servers are automatically trusted because the intermediate (signing) server’s certificates are included in a Group Policy for each of the domains. Please note that the latest CA3 cert is missing from Non-Prod domains. I have brought this up multiple times, but if a Cert shows that it can’t confirm the trust, you need to manually import the Intermediate cert to the server.

9.External Certificates – External certificates are signed by publicly trusted organizations. Microsoft includes a check in all their Operating systems after windows XP where a Public Certificate Authority is confirmed automatically prior to being trusted. On Windows XP and prior an update was required for the root Certificates to get updated. EY has recently switched from Verisign to Entrust for our Public Certificates. The Group Policies have not been updated to include the Entrust Root Certificate or the Intermediate certificate, so servers getting new Certificates may also need these certificates installs. Please note that these come as CRT files and need to be manually imported or the extension changed to .CER.

10.Load Balancers, WebSphere, Tableau, other applications – While our websphere team members deal with this more often than we will, I felt we should mention the SSL Requirements for them. Websphere like Load balancers and multiple other applications do not like the Microsoft implementation of PKCS12 certificates (PFX). As such they need to alter the certificate files to be true Pem certificates. Websphere will import a PKCS12 file (it can accept 5 different types of Key Stores), where as the load balancer and other applications such a Tableau requires the separation of the PEM Cert and Key into separate files before importing them. Most often OpenSSL is used to manipulate these files. However, that is out of the scope of this document as it is handled by those specific teams that have the specific requirements.

No comments:



Powered by Blogger.