Editor’s Note: This blog was originally posted in September of 2016. It has been reviewed for clarity and accuracy by GlobalSign Product Manager Sebastian Schulz and updated accordingly.
Sometimes, even PKI veterans struggle with ordering or installing SSL/TLS certificates. This does not suggest a lack of knowledge – rather, those processes can bring up previously unseen errors. Ordering the right certificate, creating a CSR, downloading it, installing it, and testing it to make sure there are no problems are all areas where one may encounter errors.
We want to help make the process as simple as possible from start to finish. For that reason, we collated our top queries and issues that customers may face during ordering or installation. We hope this blog will help you avoid those pitfalls and streamline your time to completion, but if you have a problem that you cannot solve using this blog you can still check out the GlobalSign Support Knowledge Base or submit a ticket.
Choosing the Right Approval Method
There are three ways to have your domain verified with us: approver email, HTTP verification, and DNS TXT record. And if at some point you grow tired of verifying domains every time you order a certificate, why not give Managed SSL a try?
Note: When ordering an SSL Certificate from our system, approval methods cannot be changed once chosen.
Approver Email
When placing an order, you can choose from the following email addresses to allow us to verify your domain:
- admin@domain.com
- administrator@domain.com
- hostmaster@domain.com
- postmaster@domain.com
- webmaster@domain.com
An email will be sent to the selected address and upon receipt of the email you can click a link to verify the domain is yours.
Note: Make sure you choose the right one, or you will have to cancel the order and start a new order.
If you do not have access or cannot set up an email from the above list, you will need to contact Support who will guide you through other possible options for email verification. These are:
- Updating the WHOIS records with an email address (an example of a website GlobalSign uses to check Who is records is networksolutions.com).
- Creating a page on the website of the domain using instructions from our support team. This will indicate control of the domain and allow the vetting team to send the approval email to ANY alternative email address.
NOTE: A dedicated support article guiding you through domain verification by approver email can be found here.
HTTP Verification
Using the HTTP Verification (also called Approver URL- or meta tag-) method, you can insert a random string provided by GlobalSign in the root page of your domain (for example domain.com). The directory chosen for this must be domain.com/well-known/pki-validation/gsdv.txt
Our verification system will be able to detect the meta tag on the page and verify the domain ownership. However, our system cannot verify the domain if it redirects to another page so make sure to disable all redirects.
Note: A dedicated support article guiding you through domain verification by HTTP verification can be found here.
DNS TXT Record
DNS TXT records entail implementing a code into the DNS TXT of the registered domain. You need to make sure the string exactly matches what you were provided at the end of ordering your certificate or from our vetting team. Also, you need to make sure that the record is publicly accessible. You can use some free online tools to check your DNS TXT records. Alternatively, you can run a command in command prompt to see if there is a txt entry, for example: nslookup -type=txt domain.com
Note: A dedicated support article guiding you through domain verification by DNS TXT record can be found here.
Private Key Missing
Ordering an SSL/TLS certificate requires the submission of a CSR and in order to create a CSR a private key has to be created. Your private key matching your certificate is usually located in the same directory the CSR was created. If the private key is no longer stored on your machine (lost) then the certificate will need to be reissued with a new CSR and therefore also a newly created private key.
Examples of error messages/situations which would indicate there is no private key:
- ‘Private key missing’ error message appears during installation
- ‘Bad tag value’ error message appears during installation
- After importing the certificate into IIS, the certificate disappears from the list when refreshed
- When going onto your website, the site does not load in https://
No matter how convenient it seems, we want to discourage the use of online tools to generate CSRs. Those will also have your private key, meaning the security of your server may be compromised in the future.
Note: We offer many guides to help you generate private keys and CSRs.
SAN Compatibility
With a subject alternative name or SAN certificate, there are several things to note before ordering:
- UCC (Unified Communication) SANs can be selected for free. Those cover some direct subdomains of the Common Name (for example, domain.com):
- mail.domain.com
- owa.domain.com
- autodiscover.domain.com
- www.domain.com
- Subdomain SANs are applicable to all host names extending the Common Name by one level. For example:
- support.domain.com could be a Subdomain SAN for a certificate with the Common Name domain.com
- advanced.support.domain.com could NOT be covered by a Subdomain SAN in a certificate issued to domain.com, as it is not a direct subdomain of domain.com
- FQDN (Fully Qualified Domain Name) SANs are applicable to all fully qualified host names, unrelated to the Common Name
- support-domain.net could be a FQDN SAN in a certificate with the Common Name domain.com
- support.domain.com would also be a valid FQDN for a certificate with Common Name domain.com, but covering this option with a Subdomain SAN is the smarter choice
- IP Addresses can not be covered by FQDN SANs
- SANs for Public IP Addresses will only work for registered and public Global IP Addresses, otherwise ownership cannot be verified
- Wildcard SANs work the same way as FQDN SANs but will cover an entire subdomain level, no matter what stands for the asterisk
- For example, the Wildcard SAN *.domain.com will cover support.domain.com, gcc.domain.com, mail.domain.com – and so on!
For the compatibility of the different SAN Types with different products, please see the table below:
It is also possible to remove a SAN after your certificate has been issued.
Invalid CSR
If you are creating a renewal CSR, then you will need to ensure the Common Name matches the one of your original CSR. The new CSR will not be the same since the private key must be different. You may not use the same CSR again, even if it seems convenient.
You can test a CSR by using the decoder in the Managed SSL Tab of your GlobalSign accounts. Should you not have that available, you can safely use online resources to check your CSR, as long as you do not share your private key you do not have to be concerned for their security. If there are any extra spaces or too many or too few dashes at the beginning/end of the certificate request, it will invalidate the CSR.
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
The Common Name You Have Entered Does Not Match the Base Option
This error appears when you are ordering a Wildcard SSL Certificate but have not included the asterisk in the Common Name of the CSR (e.g. a CSR with CN domain.com, rather than*.domain.com). Or if conversely, you have entered *.domain.com with the CSR and not selected that you wish to order a Wildcard certificate.
As earlier explained, the [*] represents all sub-domains you can secure with this type of certificate. For example, if you want to secure www.domain.com, mail.domain.com and secure.domain.com, you will need to enter *.domain.com as the Common Name in the CSR.
Note: You cannot create a Wildcard with a sub-domain before the asterisk, e.g. mail.*.domain.com, or double Wildcards, such as *.*.domain.com.
Key Duplicate Error
This error appears when you are using a private key which has already been used. A private key and CSR must only be used ONCE.
You should generate a new private key and CSR on your server and re-submit the new CSR. The reason SSL/TLS certificates have a maximum validity (and this one being cut short repeatedly) is an effort to ensure that keys are exchanged frequently, therefore mitigating the risk of undetected compromise.
Order State Has Already Been Changed
This error message generally appears when your order has timed out. You should start the ordering process from scratch and to let us know if the issue persists. If it does, we need to run further checks on your account.
NOTE: this error message can also be caused by wrongly specified SANs. For example, if the CN is "www.domain.com" and you specified sub-domain as "domain.domain2.com" which specifies a separate FQDN. Check the information about SANs above for clarification.
The SANs Options You Have Entered Do Not Match the SAN Options on the Original Certificate
This problem can occur for several reasons:
- You added a space before or after the SAN.
- There is a typo in the information you have provided.
- You are entering the Common Name (CN) of the certificate as a SAN. Following regulations, we will always add your Common Name as a SAN, this does not need to be specified.
- You incorrectly enter the SAN as a sub-domain, multi-domain name, internal SAN or IP. You need to choose the correct type of SAN which applies to the SAN. Please also check the above information on different SANs.
Certificate Not Trusted in Web Browser
After installing the certificate, you may still receive untrusted errors in certain browsers. This happens when the intermediate certificate has not been installed or for some reason the GlobalSign Root Certificate is missing from the client connecting to your server. Unless the client has been heavily tampered with, this should not occur – our Root Certificates are embedded in virtually all modern operating systems and applications.
Running a health check on the domain will identify missing intermediate certificates. If the intermediate certificate is missing, use the following link to determine which intermediate is needed based on product type (DomainSSL, OrganisationSSL, ExtendedSSL, AlphaSSL etc).
Findout more about intermediate certificates and why we use them.
‘Switch From Competitor’ Error Message
When choosing the ‘switch from competitor’ option in our certificate ordering system, you may see the following error message:
The server hosting your existing certificate cannot be reached to confirm its validity. Please obtain a copy of your existing certificate and paste it in the box below. All competitive switches are subject to review by GlobalSign's vetting team against the trusted issuers in the browser trust stores. If your certificate is not issued by a valid root CA Certificate, it will be subject to cancellation and/or revocation.
This error message occurs when your current certificate is no longer valid. You should only choose this option if you are switching before your certificate with another company expires.
This error message could also occur if your current certificate is not installed on the domain. Our system will not be able to detect the validity in this case so you should untick this option and go through the normal ordering process.
If you have a valid certificate from a competitor that is not installed on the server then you can paste your CSR into the text box using the ‘Switch from Competitor’ option. See the below image.
Finally, this error message could show when you have installed a certificate on your server but the CN is not the same as the domain name. For example, this can happen with a SAN certificate. In this case, simply untick ‘switch from a competitor’ and go through the normal ordering process.
If you are switching over to GlobalSign that’s great! If you think you should be eligible for 30 days of free validity but if you cannot go through with the process simply contact us and a team member will reach out to you.
For more help with general SSL Certificate queries then visit the General SSL page on our support site.
