HTTPS

Using LetsEncrypt with IIS via WinAcme

Andy Burns, , Leave a comment

Finally, the web is really moving to using HTTPS (thank you Google/Chrome!) This change is long overdue, and it will be good to finally be able to eliminate the vulnerability of HTTP.

“But“, cry some customers, “I don’t wanna pay for certificates!“.

Bought TLS certificates, well, cost money, and often non-technical customers don’t see any value in them. All they see is cost. If only there were a free alternative.

Good news! LetsEncrypt freely offer free DV certificates for free. That is, in fact, their raison d’être. Bad news – they only last 90 days. Bugger. Our support team won’t dreadfully want to have to renew lots of certs every 90 days. If only this could be automated… Wait, it can be!

One of my colleagues mentioned using WinAcme to get/renew certificates with LetsEncrypt, so I thought I’d give it a go. How hard can it be? Continue reading “Using LetsEncrypt with IIS via WinAcme” →

Advertisement
Using LetsEncrypt with IIS via WinAcme

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

Andy Burns, , 2 Comments

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.

Or Create a self-signed certificate for development.

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

Sitecore shell wouldn’t work over HTTPS

Andy BurnsLeave a comment

I was working at a customer recently who’s Sitecore instance wasn’t accessible over HTTPS. It was a single server, and the site itself was working just fine over HTTPS, so that begged the question – why?

The error we were getting was:

Sitecore.Context.ContentDatabase returns null.

We were using HTTPS, and it’s worth noting that rather than redirecting all HTTP traffic to HTTPS with IIS, they were using C# code and a Response.Redirect() call in their page itself, which is… unusual. It also means that HTTP traffic to Sitecore shell is not redirected – the content page layout isn’t loaded, so their redirect wouldn’t happen.

Eventually, I found the following in a patch file:

<site name="shell">
<patch:attribute name="port">80</patch:attribute>
</site>
<site name="login">
<patch:attribute name="port">80</patch:attribute>
</site>

Interesting. Shell and login were being tied to port 80 – but HTTPS uses 443.

I removed this patch, and suddenly Sitecore was available over HTTPS again.

 

Sitecore shell wouldn’t work over HTTPS

Secure your Sitecore Cookies

Andy Burns, , , , , 2 Comments

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