loading...

Windows Server 2019 – Common certificate types

How to Use the Date Command in Ubuntu

There are a number of different types of certificates that you may find yourself needing to publish. As you will see, when you need a certificate that has a list of particular requirements, you can build a certificate template to whatever specifications you like. So, in a sense, there aren’t really certificate types at all, but just certificate templates that you scope to contain whatever pieces of information are needed for that cert to do its job. While this holds true technically, it is generally easier to segment certificates into different groups, making them more distinguishable for the particular job that they are intended to perform.

User certificates

As the name implies, a user certificate is one used for purposes that are specific to the username itself. One of the platforms that is driving more certificate adoption is the network-authentication process. Companies that are looking into stronger authentication in their environments often look at certificates as part of that authentication process. Smart cards are one of the specific mechanisms that can be used for this purpose, specifically, some sort of physical card to be plugged into a computer in order for the user to gain access to that computer.

Smart cards can also be stored virtually, within a special place on newer machines called the TPM. But that is a discussion for a different day. The reason we mention smart cards here is because, often the core functionality of the smart-card authentication is provided by a user certificate that has been stored on that smart card. If you find yourself in the middle of a project to deploy smart cards, you will probably find yourself in need of a PKI.

Another popular strong authentication form is one-time passwords (OTP). This requires the user to enter a randomly-generated PIN in addition to their regular login criteria, and in some cases when the user enters their PIN, they are issued a temporary user certificate to be used as part of the authentication chain. Additional places that user certificates are commonly found include when companies employ file-encrypting technologies, such as EFS (short for Encrypting File System), or when building up virtual private network (VPN) systems to enable remote users to connect their laptops back to the corporate network. Many companies don’t want to rely purely on a username and a password for VPN authentication, so issuing user certificates and requiring that they be present in order to build that VPN tunnel is commonplace. 

Computer certificates

Often referred to as computer certificates or machine certificates, these guys get issued to computers in order to assist with the interaction between the network and the computer account itself. Technologies, such as SCCM, that interact with and manage the computer systems regardless of which users are logged into those computers make use of computer certificates. These kinds of certificates are also used for encryption processing between systems on the network, for example, if you were interested in using IPsec to encrypt communications between clients and a highly secure file server. Issuing computer or machine certificates to the endpoints within this communication chain would be essential to making that work properly. I often find myself issuing computer certificates to a business’ machines in order to authenticate DirectAccess tunnels, another form of automated remote access. There are many different reasons and technologies you may be interested in, which would require the issuance of certificates to the client workstations in your environment.

SSL certificates

If you find yourself in the middle of the certificate road, where you haven’t really managed a CA server but you have at one point issued and installed some kind of certificate, the chances are that the certificate you worked with was an SSL certificate. This is by far the most common type of certificate used in today’s technology infrastructure, and your company is more than likely using SSL certificates, even if you are not aware of them and do not have a single CA server running inside your network.

SSL certificates are most commonly used to secure website traffic. Any time you visit a website and see HTTPS in the address bar, your browser is using an SSL packet stream to send information back and forth between your computer and the web server that you are talking to. The web server has an SSL certificate on it, and your browser has checked over that certificate before allowing you onto the web page, to make sure that the certificate is valid and that the website really is who it says it is. You see, if we did not use SSL certificates on websites, anyone could impersonate our site and gain access to the information being passed to the website.

Let’s provide a quick example. Let’s say one of your users is at a coffee shop, using the public Wi-Fi. An attacker has figured out a way to manipulate DNS on that Wi-Fi network, and so when your user tries to visit mail.contoso.com in order to access their company’s Outlook Web Access to check email, the attacker has hijacked that traffic and the user is now sitting on a website that looks like their company portal, but is actually a website hosted by the attacker. The user types in their username and password, and bingo the attacker now has that user’s credentials and can use them to access your real network. What prevents this from happening every day in the real world? SSL certificates. When you force your externally-facing websites, such as that email login page, to be HTTPS sites, it requires the client browsers to check over the SSL certificate that is presented with the website. That SSL certificate contains information that only you as a company have, it cannot be impersonated. This way, when your user accesses your real login page, the browser checks out the SSL certificate, finds it to be correct, and simply continues on its merry way. The user never even knows they are being protected except for the little lock symbol up near their browser’s address bar. On the other hand, if their traffic is being intercepted and redirected to a fake website, the SSL certificate check will fail (because the attacker would not have a valid SSL certificate for your company website name), and the user will be stopped in their tracks, at least to read through a certificate warning page before being able to proceed. At this point, the user should back off and realize that something is wrong, and contact IT staff to look into the issue.

SSL certificates used by websites on the internet are almost always provided, not by your internal CA server, but by a public certification authority. You have probably heard of many of them, such as Verisign, Entrust, DigiCert, and GoDaddy. Companies generally purchase SSL certificates from these public authorities because those authorities are trusted by default on new computers that users might purchase in the field. When you buy a new computer, even straight from a retail store, if you were to open up the local store of certificates that exists out of the box on that system, you would find a list of trusted root authorities. When you visit a website protected by an SSL certificate issued from one of these public authorities, that certificate, and therefore the website, is automatically trusted by this computer. The public CAs are publicly-recognized entities, known for their capacity to securely issue SSL certificates.

When a company acquires an SSL certificate from one of these public authorities, there is an in-depth verification process that the authority takes in order to make sure that the person requesting the certificate (you) is really someone with the proper company, and authorized to issue these certificates. This is the basis of security in using SSL certificates from a public CA. All new computers know by default to trust certificates that have been issued by these authorities, and you don’t have to take any special actions to make your websites function on the internet. On the other hand, it is possible to issue SSL certificates from a CA server that you built yourself and have running inside your network, but it requires a couple of things that make it difficult, because your CA server is obviously not trusted by all computers everywhere, nor should it be. First, if you want to issue your own SSL certificate for use on a public website, you need to externalize at least part of your internal PKI, known as the Certificate Revocation List (CRL), to the internet. Any time you take a component that is internal to your network, and publicize it on the internet, you are introducing a security risk, so unless you absolutely have to do this, it is generally not recommended. The second reason it is difficult to utilize your own SSL certificates on public websites is that only your own company’s domain-joined computers will know how to trust this SSL certificate. So, if a user brings their company laptop home and uses it to access their email login page, it will probably work fine. But if a user tries to access the same email login page from their home computer, which is not part of your domain or network, they would get a certificate warning message and have to take special steps in order to gain access to the website. What a pain for the users. You should never encourage users to accept risk and proceed through a certificate warning message—this is a recipe for disaster, even if the certificate they are clicking through is one issued by your own CA. It’s a matter of principle never to accept that risk.

These issues can be alleviated by purchasing an SSL certificate from one of those public cert authorities, and so purchasing these kinds of certificates is the normal and recommended way to make use of SSL on your publicly-facing websites. Websites that are completely inside the network are a different story, since they are not facing the internet and their security footprint is much smaller. You can use your internal CA server to issue SSL certificates to your internal websites, and not have to incur the cost associated with purchasing certificates for all of those websites.

There are a few different tiers of SSL certificates that you can purchase from a public CA, information for which is listed on the authority’s own websites. Essentially, the idea is that the more you pay, the more secure your certificate is. These tiers are related to the way that the authority validates against the certificate requester, since that is really where the security comes into play with SSL certificates. The authority is guaranteeing that when you access the page secured by their certificate, the cert was issued to the real company that owns that web page.

Other than the validation tier, which you get to choose when purchasing a certificate, there is another option you have to decide on as well, and this one is much more important to the technical aspect of the way that certificates work. There are different naming conventions available to you when you purchase a certificate, and there is no best answer for which one to choose. Every situation that requires a certificate will be unique, and will have to be evaluated individually to decide which naming scheme works best. Let’s quickly cover three possibilities for an SSL-certificate naming convention.

Single-name certificates

This is the cheapest and most common route to take when purchasing a certificate for an individual website. A single-name certificate protects and contains information about a single DNS name. When you are setting up a new website at portal.contoso.com and you want this website to protect some traffic by using HTTPS, you would install an SSL certificate onto the website. When you issue the request to your certification authority for this new certificate, you would input the specific name of portal.contoso.com into the Common name field of the request form. This single DNS name is the only name that can be protected and validated by this certificate.

Subject Alternative Name certificates

Subject Alternative Name (SAN) certificates generally cost a little bit more than single-name certs, because they have more capabilities. When you request a SAN certificate, you have the option of defining multiple DNS names that the certificate can protect. Once issued, the SAN certificate will contain a primary DNS name, which is typically the main name of the website, and, further inside the cert properties, you will find listed the additional DNS names that you specified during your request. This single certificate can be installed on a web server and used to validate traffic for any of the DNS names that are contained in the certificate. A use-case example of a SAN certificate is when setting up a Lync (Skype for Business) server. Lync uses many different DNS names, but all names that are within the same DNS domain. This is an important note regarding SAN certificates: your names must be part of the same domain or subdomain. Here is an example list of the names we might include in a single SAN certificate for the purposes of Lync:

  • Lync.contoso.com (the primary one)
  • Lyncdiscover.contoso.com
  • Meet.contoso.com
  • Dialin.contoso.com
  • Admin.contoso.com

These different websites/services used by Lync are then implemented across one or multiple servers, and you can utilize the same SAN certificate on all of those servers in order to validate traffic that is headed toward any of those DNS names.

Wildcard certificates

Last but certainly not least is the wildcard certificate. This is the luxury model, the one that has the most capabilities, gives you the most flexibility, and at the same time offers the easiest path to implementation on many servers. The name on a wildcard certificate begins with a star (*). This star means any, as in anything preceding the DNS domain name, is covered by this certificate. If you own contoso.com and plan to stand up many public DNS records that will flow to many different websites and web servers, you could purchase a single wildcard certificate with the name *.contoso.com, and it may cover all of your certificate needs.

Typically, wildcards can be installed on as many web servers as you need, with no limit on the number of different DNS names that it can validate. I have run across an exception to this once, when a particular customer’s agreement with their certification authority specified that they had to report and pay for each instance of their wildcard certificate that was in use. So watch those agreements when you make them with your CA. Most of the time, a wildcard is meant to be a free-for-all within the company so that you can deploy many sites and services across many servers, and utilize your wildcard certificate everywhere.

The downside of a wildcard certificate is that it costs more, significantly more. But if you have large certificate needs or big plans for growth, it will make your certificate administration much easier, faster, and cost-effective in the long run.

Comments are closed.

loading...