Sometimes, even the most effective webmaster has problems with SSL/TLS Certificates. 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 a webmaster can encounter problems.
We want to help you make the process as simple as possible from start to finish. For that reason, we have collated our top 10 queries and issues that our customers find during the ordering to installation process. 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 contact our support team or submit a support ticket on our website.
There are three ways to have your domain verified with us: approver email, approver URL and DNS TXT records.
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:
An email will be sent to this 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 cannot set up an email from the above list, you will need to contact support who will guide you through other possible options. 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.
Approver URL
Using the Approval URL method, where you can insert a meta tag on the root page of your domain. Our verification system will be able to detect the meta tag on the page and verify the domain ownership.
Note: the meta tag must be included on the root page on the domain. Our system cannot verify the domain if it redirects to another page.
DNS TXT records entails implementing a code into the DNS TXT of the website. Use this link for checking if a DNS TXT record is present on a domain. Alternatively you can run a command in command prompt to see if there is a txt entry: nslookup -type=txt www.domain.com.
A private key and CSR must always be generated on the same server you’re installing the certificate on in order for the certificate to install correctly. If the private key is no longer stored on the server (lost) then the certificate will need to be reissued with a new CSR.
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://
With a subject alternative name or SAN certificate, there are a number of things to note before ordering.
- Domain Validated (DV) SSL Certificates only secure sub-domains and not the Common Name.
- Organization Validated (OV) and Extended Validation (EV) SSL Certificates secure multi-domain names (FQDNs).
- Up to 100 SANs can be secured on one certificate at a time; more can be added post issuance.
- Wildcard SSL Certificates can secure unlimited sub-domains represented by the asterick.
For more information regarding SAN compatibility, see the below image.
If you wish to remove a SAN after your certificate has been issued then follow the steps in that link.
On Tuesday, February 19, 2013 10:23:06 PM UTC-5, Trimble Bracegirdle wrote: That fix is dated August last. Stabby19.02.13 10:23.
If you are creating a renewal CSR, then you will need to ensure the information in it is the same as your original CSR. The new CSR will not look exactly the same since the private key is different.
Another reason why it may not work in the renewal process is when you create a CSR function in the IIS7 server. There is a known bug which will make the CSR too long. The best way to defeat this is to create a new certificate request instead of a renewal request.
You can test a CSR by using a decoder from one of the websites listed below. 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-----
This error appears when you are ordering a Wildcard SSL Certificate but have not included the asterisk in the Common Name e.g. *.domain.com. Or if conversely, you have entered *.domain.com and not entered that your certificate is a Wildcard.
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.
This error appears when you are using a private key which has already been used. A private key and CSR can only be used ONCE.
Gmail Security Certificate
You should generate a new private key and CSR on their server and re-submit the new CSR.
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 (entered) SANs. For example, if the CN is 'www.domain.com' and you specified sub-domain as 'domain.domain2.com' which actually specifies FQDN.
This problem can occur for a number of reasons:
- You have simply added a space after the SAN which our system is rejecting.
- There is a typo in the information you have input.
- You are entering the Common Name (CN) of the certificate as a SAN so the system cannot recognize if it already secured by the certificate.
- 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.
After installing the certificate, you may still receive untrusted errors in certain browsers. This happens when the intermediate certificate has not been installed.
Running a health check on the domain will show this.
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).
To find out more about intermediate certificates and why we use them, visit this article.
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 onto your server but the CN name is not the same as the domain name, as an example, this can happen with a SAN certificate. In this case, simply untick ‘switch from a competitor’ and go through the normal ordering process.
For more help with general SSL Certificate queries then visit the General SSL page on our support site.
Please enable JavaScript to view the comments powered by Disqus.
For the past week, access to a third-party email service through Gmail has stopped as of December 11 after years of trouble-free email retrieval. According to the mail fetch history panel, it's an SSL Security Error that's preventing email retrieval from the pop3 server, reporting that the SSL certificate has expired. Naturally a technical support request has been placed with the third-party provider, but now a new report indicates that Google is responsible for the Gmail SSL error thanks to a new policy.
Gmail Certificate Download
According to Slashdot, Google's Gmail servers have been reconfigured to not connect to remote pop3 servers that have self-signed certificates. Thus Gmail users trying to get email from other services may be left with an unencrypted connection, or no access to the services whatsoever.
'As of December 2012, Gmail uses 'strict' SSL1 security,' the company states. 'This means that we'll always enforce that your other provider's remote server has a valid SSL certificate. We made this change to offer a higher level of security to better protect your information.'
In other words, Google will now only accept SSL certificates from a paid provider approved by Google. The company states that Gmail users can always uncheck the 'Always use a secure connection (SSL) when retrieving mail' option on the Accounts and Import tab in the Gmail settings menu, but that also means the user's password and email will not be protected while sent over the Internet.
The other option is to notify the third-party email service of the error so they can 'fix' their SSL setup. The Slashgear report suggests that public keys should be placed on Google's side in the user configuration rather than simply dumping the problem on the user and then moving on.
'If the error is not fixed, we will disable your mail fetching and stop retrieving your messages from your other account,' Google said. 'We do not accept self-signed certificates. For a certificate to be valid it needs to chain up to a valid CA, like one in the Mozilla CA list.'
So far Google has not publicly announced the change in its SSL policy via a blog update or press release.