What is SSL?
Just to provide a quick definition: SSL is an acronym for Secure Socket Layer.
What does this have to do with SharePoint? When you host sensitive information, you don’t want it easily accessed or transmitted in plain text over the web. On any normal website, information you’re reading, submitting through forms, or sending over various protocols is not encrypted making it easy for malicious or ill intended users to sniff out and view with special applications.
The SSL Certificate (like a caped superhero) stands between this sensitive information and those nefarious scoundrels by placing encryption on your connection and validating the owner of the site you are visiting.
How Does SSL Work?
To use Fpweb.net as an example: When we manage this for you, you receive a 2048 bit Encryption through www.RapidSSL.com. This is the new standard for SSL Certificates Industry set by the Certification Authority/Browser (CA/B) Forum. The CA/B Forum requires that certificates which expire after December 31, 2013 MUST be at least 2048-bit key length. You can read more about this SSL requirement if you dare.
Why 2048 bit Encryption?
As computer power increases, anything less than 2048-bit certificates are at risk of being compromised by hackers with sophisticated processing capabilities. The cybersecurity industry is moving to stronger 2048-bit encryption to help preserve internet security.
Two Types of SSL Certificates:
When you are purchasing or renewing your SSL Certificates for your SharePoint sites, consider the type you will need: standard or wildcard.
With a standard SSL certificate, the SSL encrypts information for one address. Let’s say your website is www.yourdomainname.com. The standard SSL will cover this address as well as yourdomainname.com. For each subdomain, example.yourdomainname.com, you will need a separate certificate. This is where the wildcard shines.
A wildcard SSL certificate will apply to *.yourdomainname.com meaning that these domains would be valid;
Wildcards do have a few limitations. You can only cover a single level of subdomain – so test.example.yourdomainname.com would not be covered and would require a separate certificate.
How do you confirm the site is secure and protect your PII?
There are a few ways to confirm the site you are browsing is secured with SSL or that your SharePoint site is secure:
- The URL in the address bar will change from http:// to https://.
- If you look next to the URL, you will notice a locked padlock. Some browsers may display this along the bottom status bar as well.
- Some browsers will change the Address bar green to alert the user that they are on a secure page. If the address bar turns red, there may be something wrong with the certificate.
If you would like to view the certificate:
- Internet Explorer: Right click the page and choose Properties, then Certificates.
- Chrome: Right click the page and choose View Page Info, click the Connections tab and click Certificate Information.
- Firefox: Right click the page and choose View Page Info, Click on the Security tab and click View Certificate.
Alternatively, on most browsers you can also click on the padlock to load the Certificate as well.
With the Certificate open, look for a Valid Issuer, and that it is not expired. You can confirm this is a trusted certificate by clicking Certification Path, and checking the Certification Status. (Look for “This certificate is OK”.)
So next time you place your Credit Card or SSN in a web based form, you will know what to look for to protect your PII (Personally Identifiable Information).
How SSL Renewal Works
When you have Fpweb.net manage your SSL’s for you, we complete everything on your behalf. Thirty days prior to the SSL expiring, we receive a notice reminding us to renew your site. We will generate a CSR (Certificate Signing Request) and send it off to RapidSSL. They receive the request and perform a “WhoIs” to determine who the Domain Contact is with your Registrar (Such as GoDaddy.com, Domain.com or network-solution.com).
This comes back to Fpweb.net and lets us choose either one of the Registered Domain Contacts as listed with your Registrar if available or an Alternate Approval Email Address. While we prefer to send to a Registered Domain Contact, sometimes we see that one doesn’t exist or has been set to private through the Registrar which prevents this email address from being publicly available. This has the unfortunate side effect of not allowing a Certificate Authority such as RapidSSL from sending the approval to that email address.
Keeping this information up to date is important for many procedures such as renewing SSL Certificates. You can check your WhoIs data by visiting www.whois.com/whois and entering your domain name.
What if you don’t have a Registered Domain Contact or it’s set to private?
The approval will be sent to an Alternate Approval Email Address. These will be something common such as [email protected], [email protected], [email protected] or other common addresses. It is important to note that since a WhoIs is unable to determine a Registered Domain Contact, these alternates are best guesses. It is not possible to send this approval to anything other than what comes back on the approval notice.
As much as we would love to send the approval to [email protected], this would be a redundant security practice for a Security Certificate Issuer and opens up the possibility for Phishing attacks. If [email protected] is the appropriate email address to contact over matters dealing with your domain, then you will need to update this with your Registrar and wait for the DNS change to propagate, which can take anywhere from a few minutes up to 48 hours. We cannot CC the email to her, and we are very sorry about this.
But what if you have access to your Exchange Server?
Now, if you have access to your Exchange Server, this can cut down your time by having your administrator create one of the Alternate Approval Email Addresses and delegating this to whoever is in charge of your domain.
Once the domain contact has received and approved the SSL renewal, RapidSSL completes the CSR and sends us the SSL Certificate and we install the certificate to your server and apply it to your SharePoint site. Since you’ve read the Section above, you can check to see that the certificate has been applied and good for another year.
What’s going to work? Teamwork!
We receive many requests for SSL setup and renewals, and this document covers just about every question I’ve seen regarding them. Of course, if you have questions, feel free to sound off in the comments.
Also, check out this “Joe Knows Support” episode that covers SSL renewal as well!