A Brief Overview of Security Certificates

Ahhh… Security certificates, the security technology everybody loves to hate. Having an understanding of them and the technology that they make use of, will make things easier for you and administrators.

This page contains brief overview of security certificates and the technologies that surround them.

Certificate Details for Domain cormier.co

Table of Contents


In cryptography, a Certificate Authority (CA) is an entity that issues security certificates and is part of a larger infrastructure. For the purpose of this article, the three types of certificates are Enterprise/Domain, Public, and Self-Signed.

You don’t need your own Public Key Infrastructure (PKI) to obtain a certificate. You can obtain them from public CAs, both free and for profit. If public trust is required, you will need a certificate from a public CA.

If this endpoint is for an Enterprise, you can issue the certificate from an Enterprise CA from within the organization, the person or persons responsible for the Windows domain or Active Directory Certificate Services (AD CS) should be able to help you.

Certificate Authority (CA) & Architecture

PKI usually consists of multiple tiers of CAs. Root CA is usually offline with the private key passphrase protected and usually brought online to issue or renew CA certificates. This is the best practice as it reduces the attack surface of the PKI.

Subordinate, intermediate or issuing CAs (terms used interchangeably) are kept online and they do most of the heavy lifting of issuing certificates and serving requests for different endpoints.

PKI is lightweight but is an important service. Much like DNS the footprint and resource usage are small, but the service remains to be an essential part of the network infrastructure, especially in Active Directory domain and HTTPS/TLS endpoints.

High-availability (HA) is not always about the resources a service requires, lightweight services like PKI and DNS will require resources for fault tolerance. For example, four (4) DNS servers, even though a single server could handle the traffic of the four (4), you would be reduced to a single point of failure. But, four (4) gives the DNS service layer stability against outages, maintenance, and human errors. For PKI, this could mean having HA endpoints for OCSP/CRL to avoid service disruption and error messages for users, for example.

Having a reliable PKI goes a long way in providing security services to the network, devices, and applications that use that infrastructure.

Certificates & Private Keys

When issued a certificate you’ll receive an X.509 certificate, public and private in possible different formats. Usually downloadable in Privacy Enhanced Mail (PEM) the de facto file format for storing and sending cryptographic keyscertificates, and other data, or binary Distinguished Encoding Rules (DER) format.

Other solutions may provide a single certificate archive file, with certificate(s) and private key. Also, know as PFX files because of their extension, can contain additional certificates, like issuing and root CA certificates as some systems will require the full certificate chain for trust verification.

Note: Don’t lose or leak the private key, it’s the only line of defense from the traffic from being decrypted by nefarious sources. Having the private key compromised will lead to the need to revoke the certificate and place it on Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) lists and require re-keying and issuing a new certificate.

Certificate Types

Enterprise/Domain certificates are issued by an Enterprise CA or Subordinate CA under the control of an organization. In a Windows domain, this is typically Certificate Services by Microsoft, although this can be another platform or service.

Public certificates are issued by a public CA. CA services have different levels of verification of the entity requesting certificates. Usually, for standard certificates domain control validation is used. Web certificates can have Extended Validation (EV) and attempt to validate not only control over the domain but additional details about the domain owner. Some browsers display this additional identity information in a green box in the URL bar.

Self-signed generated certificates using to get software or service installed. These types of certificates are usually the certificate an endpoint will be using if not configured to use another certificate. The self-sign certificate isn’t trusted, so it will have to be replaced with a certificate from an enterprise or public CA. Note, you can click through these warnings, but other non-web based tools won’t be able to do this and will get connection errors due to trust.

Certificate Signing Request

In order to request a certificate, you will need a Certificate Signing Request (CSR), even if you’re not creating the CSR, it will still be created as part of the request process, and the correct information will need to be passed along to the right people.

Microsoft IIS Certificate Request

Typically you make a request for a certificate via web form or file submission. If the type of certificate is Enterprise, this typically goes to security, system administrator, or IT department of your organization.

If external trust is a requirement, submit the necessary information to public CA to obtain a certificate for a monetary cost.

Public certificates are signed by organizations that have their CA certificates in Mozilla’s CA bundle, which is the bases for a lot of key stores. This will give your certificate trust by browsers and other applications that make use of their CA bundle.

Security Administrator will need the following information to create the request.

  • Common Name (CN) of the endpoint serving the certificate. Also referenced as Subject.
    • This field uses the Distinguished Name (DN) notation from the Lightweight Directory Access Protocol (LDAP) standard
    • For example, vpn.example.org would be a valid CN for a VPN headend certificate.
    • If you want the endpoint to be trusted as both hostname (vpn) and FQDN (vpn.example.org), you will have to include both on the certificate, using a Subject Alternative Name (SAN).
  • Organization (O)
  • Organizational Unit (OU) or Department
  • City (C)
  • State (S)
    • Spell this field out, don’t use abbreviations. For example, Nova Scotia instead of NS.
  • Country (C)

Other information like usage, extended usage, and key lengths might also be required, identify what is required for the certificate from the documentation, support, vendors, etc. If you are working with Microsoft Certificate Services, CA templates can make life easier. For example, the Web Server template has the necessary attributes for web server certificates and will include the necessary attributes for basic web server certificates.

When creating certificate requests for Windows applications a lot of times it will provide a wizard or utility to generate an appropriate CSR and save it to a file or make the request through an Online CA.

Other methods include using Certificates MMC or command-line utility certreq.

Vendors have been known to provide scripts that do most of the work for you. Create the request, submit the request to Online CA (found through Active Directory query), issue the certificate, installs the certificate and sets IIS HTTPS binding to the new certificate. Others will simply save the CSR to a file for processing, depends on the effort put in by the vendor. Provided you have the permission and everything else you provide the script is correct, it should issue a certificate.

If you’re using a variety of Unix/Linux, you will need to get comfortable with OpenSSL, this command will be used to generate a private key and request as separate files.

$ openssl x505 -req ...

Other platforms reference their documentation for request creation. For example, macOS has Keychain Access and the command line utility certtool to manage certificates.

Key Stores

Certificates are stored in key stores. Stores are builtin to Operating Systems (OS), browsers, and other places.

Windows and macOS have key stores that applications can access via API or Console, while Linux doesn’t have a key store and places certificate files in specific locations for applications to load. Directory under /etc/ is a common storage location, /etc/ssl for example.

Chrome and Firefox have key stores and for these browsers to trust Enterprise CA-signed certificates, CA certificates will need to be imported before they will trust internal sites. You can do this manually or through some other automatic method.

The enterprise way to do this is through Group Policy, add the certificates to a Group Policy Object (GPO) and link it to the appropriate Organization Units (OU) within your Active Directory. Other methods depend on the device and certificate, device certificates could be sent via Intune, were as user certificates could be issued on a piece of hardware.

Java key store, Java KeyStore (JSK), and commands to administer key stores in this format. See keytool for more information.

Client Certificates

Not used nearly as often as server-side certificates. Client certificates can be issued for a variety of reasons, authentication for Wi-Fi Enterprise networks, Remote VPN, smart cards, secure web authentication, etc.

A lot of this is can be transparent to end-users, renewals can take place automatically, or issued on a new smart card, and they never really have to deal with them, just present them when required and continue on with work.

The back-end will require additional administrative overhead. More certificates for CA to handle, additional complexity to troubleshooting client issues, complicates authentication. But the end-user will be more secure for it, even if it makes their workflow a little different or harder. People are not a fan of using smart cards or fobs.


Verification of certificate a secure endpoint is serving can be done with openssl s_client command from a Unix type system or through a browser.

Browser Certificate Details

If you are working from a Unix/Linux system and want to verify an endpoint, use openssl s_client command

$ openssl s_client -connect https://cormier:443

Next, update any references to the certificate properties (hash) and/or one of its attributes. For example, Exchange connectors reference certificates by Issuer and Subject. References like these will need to be updated manually a lot of the time.

A proxy can also cause issues with certificates and connection errors do to trust, etc. Look for certificates that belong to the proxy device or service in error logs and events. Depending on the service or device you can upload your own certificates forget the trust you require. Other times, you might not have this control and will have to deal with it or find a workaround.


Algorithms are what bring confidentiality, authentication, integrity (CIA) to PKI. The inner works of these aren’t as important to administrators as what algorithms to use and where.

As a security administrator, you need to keep up to date on which algorithms are current and which legacy algorithms should you avoid, SHA-1 is a good example of an algorithm that once was the hash algorithm to use, but over time attacks have advanced, making it no longer useful for security applications, but will remain in use for file checks, etc.

You have your symmetric encryption algorithms and you have asymmetric (Public Key, which this page is about). The former is used for fast encryption operations on data, which requires sharing a key to another party for them to be able to decrypt.

Symmetric algorithms like the older DES and 3DES. The current standard is AES.


It’s helpful to know which standard refers to which technology as documentation will at times reference the standard name. Public Key Cryptography Standards (PKCS)


Diffie-Hellman Key Agreement standard. The standard applies the sharing of secrets across an untrusted network without prior information. Hosts simply exchange keys and are able to negotiate a secure key exchange, giving other algorithms a mechanism to get this feature.

PKCS #10

Certification Request Standard. Format of messages sent to a certificate authority to request certification of a public key.

PKCS #11

Platform independent API for cryptographic tokens. Often used with hardware modules, single sign-on, disk encryption, and other encryption systems.

PKCS #12

Defines an archive file format for storing many cryptography objects as a single file. It is commonly used to bundle a private key with its certificate or to bundle all the members of a chain of trust. PFX is a predecessor to PKCS #12. See RFC 7292.

This archive format is usually protected with a passphrase.

Usable as a format for the Java key store and to establish client authentication certificates in Mozilla Firefox.

PKCS #13

Elliptic Curve Cryptography (ECC)

PKCS #14

Pseudo-random Number Generation. Standards that define pseudo-random numbers, which is a requirement by most to obtain reliable seed and initiate vector values for algorithms, otherwise attackers would have known information about the operation, giving them an advantage.

No comments
No comments yet.

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>