How HTTPS Certificates Work?

News Knowledge Base
,
1

How HTTPS Certificates work?

How HTTPS Certificates Work?

Many times user struggle to manage the HTTPS certificates used for TLS encryption between client and server. Often times the issue is a lack of clarity on what a certificate is for and what the requirements are. This is a very brief primer on the key details to know (There are many resources across the internet that can explain certificates in full detail):

  1. The purpose of certificates is to make the internet safer (among other things).
  2. Anytime a browser connects to a website using HTTPS, a certificate is involved. A secure site looks like:

  1. A certificate is a document that can be used to establish if a website is trust worthy (It is just a long random looking string). How that trust is established is done using complex mathematical operations. Observe the following:
    1. Root Certificates are certificates that we trust directly. For these certificates, there exists an actual file on the computer that contains the certificate. Because the file exists on the computer in the right location, it can be trusted
    2. Certificates can be chained together. So if there is Certificate A, which is trusted and it says certificate B can be trusted, then trust Certificate B. The correct term for this would be that Certificate A issued Certificate B. This can be extended further.
    3. When connected to a site, it presents a certificate to the browser, if that matches one of our Root Certificates or if its issued by one of our Root Certificates, we trust it. If the site is trusted, then it is marked as secure by the browser.​​
    4. Behind the scenes, every certificate has a private key. This is used to issue certificates and it should never be shared. (You can share a certificate without sharing the private key)
  2. Certificates also have metadata. In the context of HTTPS the most important attribute is called the 'Subject Alternative Name' (SAN). This is the name of the server that is being connected to (usually the FQDN). Some admins might simple refer to this as the DNS name. For any URL, determine what the value of the SAN should be. Here are a few examples:
    1. https://google.com -> The SAN should be google.com
    2. https://uipath.com/docs -> The SAN should be uipath.com
    3. https://insights.mycompany.com/home -> The SAN should be insights.mycompany.com. The domain would be mycompany.com.
    4. https://insightslinux.mycompany.com/login -> The SAN should be insightslinux.mycompany.com. The domain would be mycompany.com.
  3. If the SAN does not match the URL being used, a browser will mark the site insecure (even if it trusts the certificate).
  4. A certificate can have multiple SAN entries. The SAN entry is always a valid DNS name.
  5. A few other things:
    1. There are what is called Public Root Certificates. These come from well known organizations (DigiCert, AWS, CloudFlare, etc). They not only issue certificates but they ensure that they only issue certificates to websites that actually own the domain. For example, no one but the company UiPath can request a certificate with the SAN attribute uipath.com from a public Root Certificate company because the domain is owned
    2. Internally within a companies intranet, a company can have its own Root Certificates. These are Private Root Certificates but are like public root certificates in the context of the companies intranet. Companies usually have an internal root certificate provider that is used for internal sites. This allows them to issue certificates for internal sites without having to buy certificates from a public certificate authority. For example a certificate may be issued for a site called: rpa.mycompany.internal.
    3. For companies with internal root certificates, they usually automatically install these certificates onto the machines connected to their intranet.
  6. This means that for a site to be secure the following conditions must be met:
    1. The SAN attribute matches the server name in the URL.
    2. The certificate presented by the website needs to be a Root Certificate or issued by a Root Certificate.
  7. This also means that UiPath cannot provide these certificates for end users. For us to issue a certificate for an on premise environment, either, own the domain or access should be obtained to the companies internal Root Certificate's private key, which is something that should never be shared.
    1. Create self-signed certs. These are new Root Certificates. However, these certificates would have to be installed on every users machine manually, and tend to lead to more complications. For example, if the certificate is not installed on a users machine, they can usually bypass the certificate warning, but many other things would break.
  8. With the above in mind, these are the important things to know:
    1. Almost all companies have an internal root CA
  9. Almost all companies have a well defined well defined process for requesting a certificate issued by an internal root certificate. The biggest challenges are:
    1. Being aware of this process
    2. Understanding the SAN attribute and requesting the server name correctly.
    3. The same process used to issue a certificate for a Windows machine can be used for a certificate that will be used on a Linux machine.