You’re probably not going to select dress shoes to wear to the gym. In a similar way, the SSL/TLS certificate you select depends on what it’s being used for. There are different certificate types developed to satisfy various use cases.

Once you assess your business requirements, you will be able to determine which is the right SSL/TLS certificate or certificate mix to encrypt your web application(s) – or you can ask an expert. For the do-it-yourselfers, here are some common use cases and the type of SSL/TLS certificate recommended for each.

Common Use Cases for SSL/TLS Certificates

HTTPS Connection for a Single Domain

This represents someone with a basic website, landing page, or another web-based project that has only one possible domain via HTTPS (e.g., https://www.example.com and https://example.com)

Recommendation

  1. If sensitive information is requested (e.g., login credentials or credit card transactions) for client-to-server transmissions, an EV certificate is recommended because it offers the highest identity assurance and an added visual indicator in the browser.
  2. You might also consider a Standard OV certificate, which has some identity assurance as a lower cost alternative.

HTTPS Connection for Multiple Domains

Useful for an organization with a basic website secured with SSL/TLS and the site allows multiple domains for HTTPS delivering the same web content (e.g., https://www.example.com, https://example.com and https://example2.com)

Recommendation

  1. If sensitive information is requested (e.g., login or credit card transactions) for client-to-server transmissions, an EV certificate is recommended for highest identity assurance and the added visual cue.
  2. You might also consider an Advantage OV certificate, which has some for identity assurance as a lower cost alternative.

If additional domains, subdomains or SANs  are required, a UC Multi-domain Certificate will cover you (e.g., mail.example. com, buy.example2.com, etc.).

Microsoft Exchange, Lync or Skype for Business Server

This use case typically involves encryption at multiple end-points because a unique domain for each service is usually required in desktop client-to-server environments using a Microsoft Exchange server: Webmail/IIS, SMTP, POP, IMAP and UM.

Recommendation

  1. If sensitive information is requested (e.g., login or credit card transactions) for client-to-server transmissions, an EV certificate is recommended for highest identity assurance and the added visual cue.
  2. To secure multiple domains on one certificate, a UC Multi-domain/SANs certificate is recommended. UC Multi-domains are also useful whenever there’s a need to secure multiple names across different domains.

Server to Server

Situations when mutual authentication between two servers is needed and the certificate extension, EKU, requires client authentication (e.g., Exchange TLS between two organizations where one organization has a server with data that it needs to send to a third-party for processing. This is where mutual authorization is used that does not require a browser).

Recommendation

  1. Standard OV certificate that supports Client and Server Authentication

HTTPS for a Domain and an Unlimited Number of Its Subdomains

An efficient method that secures a domain and an unlimited number of its subdomains across an unlimited number of servers, which saves time and money.

Recommendation

  1. Wildcard certificate, if they
    1. share a common root domain (e.g., *.example.com),
    2. multiple identical servers are required, for example load balancing
    3. a duplicate certificate is needed for a hybrid RSA/ECC deployment

While a Wildcard certificate enables administrative efficiencies for a domain, they bring security vulnerabilities at the server. Entrust Datacard recommends using Best Practices including SSL Server Testing and other safeguards when deploying Wildcard certificates. Check out our white paper, Private Key Duplication: The Safe Use of Wildcard and Multi-server Certificates.

HTTP Security for Non-registered Domain Names

A method to secure internal domains, non-fully qualified domain names (Non-FQDNs), which aren’t registered and reserved IP addresses.

Recommendation

  1. Private SSL/TLS Certificates provide an easy and affordable method to secure domains that don’t require public trust. Private certificates provide the same key sizes, signing algorithms as publicly trusted SSL/TLS certificates — but are issued via a privately shared CA that protects you against possible impersonation attacks by ensuring no two certificate names are alike.
    1. Private SSL/TLS eliminates the cost of running and maintaining an internal CA.  Private SSL/TLS are not limited to Non-FQDNs, and
    2. can be used for any internal network where an organization might be considering the use of an internal PKI/CA.

These are some of the most basic use cases for SSL/TLS certificates.

7-Part Blog Series

  1. SSL/TLS 101 – Why Do I Need an SSL/TLS Certificate
  2. SSL/TLS Certificate Types – Choosing the Right One for Your Use Case
  3. SSL/TLS Verification – Digital Identity for Your Website
  4. What is a SAN (Subject Alternative Name) and how is it Used?
  5. What is a CSR and How Do I Get One?
  6. What’s the Difference between a Public and Private Trust Certificate?
  7. How to Build an SSL/TLS Certificate | The Five Simple Steps That Bring You to HTTPS

Additional Resources
Which Type of SSL Certificate Do I Need?
How Does SSL/TLS Work?
Bi-Weekly Certificate Management Demo