Scott Helme has posted a number of interesting blog posts recently:
I mean, he’s a bit of a LetsEncrypt fan, but equally, their certificates are as good as others, and EV Certs and SSL Warranties do seem to be sources of revenue generation, rather than offering something useful.
What I’d really like is an easy way to use LetsEncrypt with IIS; for a long time it has seemed like a second-class citizen. Or maybe scripting is just more awkward in Windows. Either way, it’d be great to have simple tooling to support automatically renewing IIS site certs.
Then we could reduced certificate lifetimes and overcome the problems of the broken revocation process in certificates.
This is a bit of an aide-memoire, based on https://blogs.msdn.microsoft.com/benjaminperkins/2017/11/15/how-to-create-a-self-signed-san-certificate-wildcard-certificate-vs-san/
The short form is, you can do this in PowerShell:
- Open Powershell, running as administrator.
New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -DnsName "example.local" -FriendlyName "example.local" -NotAfter $([datetime]::now.AddYears(5))
- Go to “Manager Computer Certificate” or run CERTMGR. You should see your certificate
Next, we want to trust this certificate. We’ll need to export it.
- To export the certificate file you just created as a .PFX file, right click on the certificate, All Tasks -> Export…
- When the Export menu item is selected, an export wizard is run. On the first window read through the information and click the next button.
- In the next window, select the radio button “Yes, export the private key” and then click the next button.
- Select Export Extended Properties, and click next
- Set a password for the .PFX file you want to create#
- Choose a path and export the .pfx file
Now import it into the “Trusted Root Certification Authorities” that you can see in Certificate Manager
- Expand Trusted Root Certification Authorities –> right-click Certificates –> All Tasks –> Import.
- Select the file you just exported. Note that you may need to change the file type to Personal Information Exchange.
- Click Next, Fill in your file’s password, and complete the import.
That should be it completed.
Yesterday, I had a working development site suddenly start throwing SSL errors:
The error message was:
This server could not prove that it is [Server Name] its security certificate is from [missing_subjectAltName]
Huh? What broke this?
Well, it turns out that Chrome had updated to Chrome 58, which removed support for the “Common Name” field. Instead, we’re supposed to use the “Subject Alternative Name” (SAN) field. That’s unfortunate; the IIS ‘Create Certificate Request‘ option we’d used resulted in a certificate with no Subject Alternative Name field. That could be a result of how it was handled – I didn’t create the certificate – but it looks like Windows MakeCert doesn’t handle Subject Alternative Names, so I wouldn’t be surprised if this is a general Windows issue.
The SSL cert continued to work without a SAN just fine in IE, but Firefox and Chrome now demand it, and so were throwing SSL errors.
Now, it seems that the Subject Alternative Name is what we’re actually supposed to use, and that publicly trusted certs have used both fields for years – but in our development server, using our own CA, that wasn’t the case.
See How to Request a Certificate With a Custom Subject Alternative Name.
So a Sitecore site I’ve been working on recently underwent a penetration test, which turned up an interesting item. The ASP.NET_SessionId and SC_ANALYTICS_GLOBAL_COOKIE cookies aren’t set with the ‘Secure’ flag. Further, my own checking showed that the .ASPXAUTH token was also set without the ‘Secure’ flag.
As the entire site is only served over HTTPS, this seems to be a bit remiss.
Fortunately, there are a couple of easy fixes to this that can be set in the Web.config
<httpCookies> set requireSSL:
<httpCookies requireSSL="true" />
<forms> set requireSSL too.
<forms name=".ASPXAUTH" cookieless="UseCookies" requireSSL="true" />
This latter one is needed for the .ASPXAUTH cookie, but that seems to do it.
Don’t forget to set the HTTPOnly flag as appropriate for your cookies too!
I’ll admit, I find the configuration of SSL and TLS something of a mystery – I like to leave that stuff to the admin guys and get on with the coding. It’s something of a black art, and there seem to be so many obscurely named vulnerabilities that it’s a bit difficult to handle without being a specialist. (Heartbleed? Bar Mitzvah? Lucky 13? Poodle? I mean, seriously, POODLE?)
However, I was recently given a PowerShell script and told to ‘fix these servers’ – and it was very easy. Continue reading “Configuring SSL/TLs made easy”
I was asked to use a GMail server to send emails from Sitecore with. This is actually a pretty reasonable request – but GMail only supports connections over TLS or SSL. Configuring Web Forms for Marketers to use this was proving … interesting, until I found this excellent article by Mark Cassidy. Continue reading “Enable SSL for sending emails on Sitecore”