This server could not prove that it is … its security certificate is from [missing_subjectAltName]

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.

This server could not prove that it is … its security certificate is from [missing_subjectAltName]

Secure your Sitecore Cookies

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

Under <System.Web> and <httpCookies> set requireSSL:

<httpCookies requireSSL="true" />

And in <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!

Secure your Sitecore Cookies

Configuring SSL/TLs made easy

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”

Configuring SSL/TLs made easy

Enable SSL for sending emails on Sitecore

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 CassidyContinue reading “Enable SSL for sending emails on Sitecore”

Enable SSL for sending emails on Sitecore