loading image
Verifying Domain loading image
SSL Glossary Image

Glossary Terms

Explanation of Terms

Approver email

This is the email chosen by you during Certificate Enrollment that is used by the CA to validate that you own the domain. To ensure the certificate is requested by the domain owner, only certain email addresses can be used for this purpose. Only the emails registered to the domain's WHO.IS (the legal record of ownership) or one of five pre-approved email addresses (which are: [email protected], [email protected], [email protected], [email protected], [email protected]) may be used. Alternatively, you can use File-Based Validation or DNS C-Name validation.


Browser Compatibility

Browser Compatibility, represented as a percentage, showcases the actual support of that particular SSL Certificate across a majority of browsers. This number is based off how many devices the issuing Certificate Authorities' Root Certificate is included on. However, please note that this number is an estimate, based off an average consumer with an updated device. The client's browser, operating system and the certificate hashing algorithm may affect this. Read More


Certificate Authority and Browser Forum (or CA/B Forum):

Voluntary association of Certificate Authorities and Web Browsers who share a common goal of setting and enforcing standards for certificate issuance and processing. The CA/B Forum sets regulations related to SSL certificate validation and technical requirements, which all publically-trusted certificates are required to conform to.


Certificate Chain

The certificate chain consists of every certificate required to verify the common name listed in the end certificate (end-entity). The industry relies on Certificate Chains for security purposes as well as administrative purposes. Typically, the Certificate Chain consists of an end-entity certificate, intermediate certificate, and root certificate.


Certificate Enrollment (or Certificate Generation)

This refers to the process of inputting relevant certificate information – mainly the CSR (Certificate Signing Request) and required contact and organizational details. This process occurs after purchasing a certificate and is required for the CA to receive your information and undergo validating your request to issue a certificate.


Certificate Renewal

Before a certificate expires, it is important to make sure you have renewed and replaced it with a new certificate. A certificate's expiration date cannot be extended, so renewing requires purchasing and generating a new certificate. When renewing, you should generate a new CSR (Certificate Signing Request) to ensure proper security of their certificate. After filling out the certificate details and going through the validation process again, the CA will issue the renewal certificate which will allow you to install it so SSL coverage can continue without an interruption in service. Renewal reminder emails are sent out regularly to ensure you have a chance to renew early. Remember that the validation process can be lengthy, even if you have already validated the previous year. Industry requirements require periodic re-validation so please allow ample time to avoid SSL-related issues.



Short for Certificate Signing Request, a CSR is encoded text that contains information about the certificate requester. This information includes, but is not limited to, the domain name for the certificate (referred to as a “Common Name”), organization name, and a contact email for the certificate. When creating the CSR it will export two files, these two files will be your CSR which will be requested during enrollment, and a corresponding private key which should not be shared and will be required during installation.


Code Signing

This certificate is used to protect executable software from unintended modification. While a Code Signing is technically similar to an SSL Certificate it serves an entirely different purpose – it does not interact with websites. The Code Signing Certificate attaches a digital signature to the executable file, and before the file is run, the Operating System will be able to use the signature to determine if any changes were made since it was signed. These changes could be corruption which occurred during a download, or a malicious change such as malware added to the executable. If any changes – even a bit of data – have occurred, the Operating System will prevent the program from running and display security warnings.


Domain Control Validation (DCV)

DCV is how you prove ownership of the domain requested in your CSR. There are three methods of DCV: E-mail-Based Validation, File-Based Validation and DNS C-Name Validation. During Certificate Enrollment, you are free to choose your desired method. You will need to complete the required steps as part of the certificate issuance process. If you are confused on how to complete the chosen method, or need to switch methods, please contact our support team.


Domain Name System (DNS)

The Domain Name System serves as the phone book for the Internet by translating human-friendly computer hostnames into IP addresses. For example, the domain name "www.example.com" translates to the addresses Every website has configurable DNS settings which can be used to route connections being made to that server. Custom DNS configurations can be made to demonstrate ownership of a domain and satisfy industry requirements to receive an SSL certificate.


Dun and Bradstreet (D&B)

A third-party credit reporting agency that provides verified information for business-to-business transactions. Your company may have a record with Dun and Bradstreet, which would be referred to as your 'DUNS Number'. Depending on the certificate you've purchased, the Certificate Authority's Enrollment Form may have a field asking for your 'DUNS Number'. Certificate Authorities (CAs) have deemed Dun and Bradstreet to be a reputable source to obtain information such as a businesses registered name, address, and telephone number, which they use to fulfill the requirements of the SSL validation process.



Elliptical Curve Cryptography (or ECC) is an alternative to the typical RSA encryption model which is currently the most common. ECC is faster, stronger and uses smaller key sizes (112 or 128 bits compared to an upwards of 2048-bits with RSA). It is a much more advanced method than RSA, however some devices lack compatibility for it. Currently, ECC keys are offered with DigiCert's "Pro" line of SSL Certificates. Compared to a 2048 RSA key (which is the industry norm), ECC-256 keys are 64,000 times harder to crack.


Email-Based Validation

A method for confirming ownership and control of the domain name requested for your SSL Certificate. This method allows you to choose to confirm the certificate via an email address associated with the requested domain. Only certain email addresses are suitable for proving ownership. Those being emails registered on the WHO.IS, or 5 pre-approved emails (which are [email protected], [email protected], [email protected], [email protected], [email protected]). The alternative methods are File-Based Validation and DNS C-Name Validation.


File-Based Validation

A method for confirming ownership of the domain name requested for your SSL Certificate. This method requires that you upload a provided file to your webserver. If it is easy for you to upload a file to your site via FTP, then this will be a simple process to perform. The alternative methods are Email-Based Validation and DNS C-Name Validation.


Fully Qualified Domain Name (FQDN)

A fully qualified domain name is the complete domain name for a specific server. FQDNs are made of three parts: the subdomain, root domain, and TLD (top-level domain). In the example case of www.rapidsslonline.com, "www" is the subdomain, "rapidsslonline" is the root and "com" is the TLD. You will need to know how many FQDNs you need to secure when considering what SSL certificate you need. For the purposes of a multi-domain certificate, you need a SAN for every FQDN. Note that "rapidsslonline.com" is a separate FQDN even though it has no subdomain. Some certificates may include coverage for the "www. subdomain and root", indicating they cover both those FQDNs when either is requested


Intermediate Certificate

These certificates establishes the bond between the issuing Certificate Authorities' Root Certificate and the Server Certificate (which is the SSL certificate for your server). Certificate Authorities (CAs) will include the Intermediate Certificate(s) and sometimes even a Certificate Bundle (all the Intermediate Certificates packaged together in a '.zip' format) with your Server Certificate. In order to be trusted, you will need to install all of these files and the SSL certificate properly on server. Without installing the Intermediate Certificate(s), your visitors could be greeted with possible warnings stating that the site is insecure/not trusted in their browser.


Mixed Content

These warnings may be displayed by a web browser when the website being viewed has a mix of resources loaded over HTTP (insecurely) and HTTPs. Because some content was loaded insecurely, the browser responds by showing a degraded security indicator – usually a padlock that is grey or with accompanying symbols. This can be remedied by updating HTML code making calls over HTTP and load all images, videos, scripts, or images over HTTPS. We recommend to use the Developer Console in your browser (accessed via "Ctrl + J" in Google Chrome) or go to WhyNoPadLock.com and check what lines of code need to be updated to HTTPS.


Multi-Domain Certificate

This type of SSL allows you to secure multiple domains or (FQDNs) within one certificate. The certificate has a "Common Name" as all certificates do, but also has the functionality of supporting additional domain names through use of the "SAN" (Subject Alternative Names) functionality. When purchasing a certificate, you will be able to specify how many SANs you need – each FQDN uses a SAN. Also, during the Certificate Generation process, you will have the ability to specify those SANs after pasting the CSR.


Private Key

This is a file that needs to be securely stored on your server. When you generate your CSR, a Private Key will also be generated. It is essential that you save this and securely store it – without the private key your certificate will not function and will need to be reissued. If a Private Key is comprised, you should alert our support team so we can assist you. SSL uses a system known as Public Key Infrastructure to securely transfer information, to learn more about it please see the definition of "Public Key".


POL (Professional Opinion Letter)

Used to verify organization details that were not available in current public resources. This letter can complete multiple steps of the OV/EV certificate validation process. Keep in mind that it must be attested by a legal counsel or a professional/chartered accountant. Because those professionals charge for their services, we strive to keep the cost down for our customers. If you think you need to use a POL, please contact us to see if other forms of validation/alternatives are available before this is resorted to. Specifically, the POL can be used in verifying the organization name, registration details, physical address, telephone number, domain name, operational existence, and employment verification of organization contact.


Public Key

Contained within your SSL Certificate is your server's public key, and its one half of your key pair (the private key being the other half). The industry standard is a RSA 2048 bit key (recommended), however, RSA 4096 bit keys and ECC keys are also available for more security. The public key is one of two keys used in public key infrastructure (PKI) – a big term, we know. In a typical PKI system, the client would encrypt their data using the server's public key, then the server would decrypt the data using its private key. This allows the information to be sent securely, without needing any previous relationship between the client and server.



A certificate is reissued when the owner needs to make some changes to the certificate. While reissues can be done anytime during the life of the certificate, some changes can only be made within the first 30 days after issuance. Reissues are generally made when the private key/CSR needs to be replaced, when organizational details need to change, the hashing algorithm (SHA-1/SHA-2/ECC) needs to be changed, and/or SANs need to be added/removed/changed (multi-domain certificates only). Reissuing a certificate does not change the validity period of the certificate and is free of charge (unless purchasing additional SANs). Please note that you can NEVER change the common name (the primary domain name requested in the CSR) after a certificate is generated. If you need to change your Common Name you may do so for free by Canceling & Reordering, but only if your certificate has been issued for less than 30 days or hasn't been issued yet.



An RSA Key is a type of key that handles the encryption of data transmitted through the SSL protocol. You will always have a "key pair" – consisting of a private and public key. This is a .key file that will be generated at the same time as your CSR. If you generated your CSR using an online tool in your web browser, the RSA private key would have been presented along with your CSR and should be saved to your local computer or server. If you generated your CSR directly on your server, the key was likely saved automatically. There are other types of key pairs available – the most notable being ECC.



Both SHA-1 and SHA-2 are mathematical functions that computer devices use to verify the integrity of an SSL Certificate. Specifically, they are hashing functions which output a unique hash value for every input. This hash value will be tied to the SSL Certificate that is issued out by the Certificate Authority (CA) for verification purposes. When filling out the enrollment form, you'll be prompted to choose which hashing function you'll want to use. The form will default to the current industry standard - SHA-2, but SHA-1 and ECC may also be available if you have a need for them.


Subscriber Agreement

The issuing Certificate Authority (CA), requires you to read and sign this document for Extended Validated Certificates. Domain and Organization Validated Certificates do not require this document to be signed.


Wildcard SSL Certificate

A Wildcard SSL Certificate is a special purpose SSL certificate that allows you to cover an unlimited number of subdomains at a specific level for one domain name (FQDN). All Wildcard SSL Certificate use the asterisk symbol, "*", to indicate the ability to cover any possible subdomain. For example, a Wildcard SSL Certificate for "*.domain.com" would secure "www.domain.com", "mail.domain.com" or "xxyyzz.domain.com". However it would not cover "www.domain.net" or "www.website.com"; it may also not include coverage of "domain.com" but that will depend on the specific certificate.



TCP-based query/response protocol that used in the industry as a means of investigating a IP/domain names registered users list. Information such as the organization name, address, phone number, etc. can be queried through the use of WHO.IS.


Why RSO Image

Why Choose Us?

As an SSL Pioneer, there have been 400,000+ site owners that love our convenient selection of the world’s most popular solutions, streamlined support, awesome experts and unlimited resources & tools to get the job done right at an EXTREMELY AFFORDABLE RATE!

  • Google Chrome web browser image
  • Microsoft Edge web browser image
  • Firefox web browser image
  • Opera web brower image
  • Safari web browser image

Our certs are supported on 99.9% of web browsers, iPhones & mobile devices

Our Awesome Customers

View SSL reviews & testimonials