I recently put together a PKI and I decided it was time to experiment with certificates with subject alternative names (SANs) today. I immediately fell into an easy trap!
If you make a certificate with a SAN, you MUST have the address you use for the CN in the SAN field too. It seems if you have a SAN then ISA server will see this and only look for the DNS identity of the website it’s going to in the SAN field, instead of looking in the CN field too.
This leaves you with a “500 Internal Server Error – The target principal name is incorrect” error which is somewhat confusing!
So say you want a certificate that is valid for the following addresses:
What you must do is ensure you have the following field entries in your certificate:
In that way the CN is used as an identifier, and the san’s are used in the validity verification checks by ISA. Note however that IE and Firefox will still use the CN for validity checking as well.
One of my favourite things here at UWE is managing our ISA 2006 system, and this week I got bogged down with development websites being requested left, right and centre. To top it off they wanted their sites to have certificates too, and ISA server insists that you use one IP address per certificate. I knew about wildcard certificates (*.domain.com) but not actually tried them on ISA before, so I thought I’d solve my dev-problem with one.
Following the handy guidelines from isaserver.org, which are for ISA 2004 but still relevant for 2006, I created one listener with a wildcard certificate and rules for all the sites. Apparently one of the new things in ISA 2006 is the ability to use the wildcard certificate on the IIS site as well as on the ISA listener, but we’ll come back to that 🙂
After configuring I found http access would get to all the site just fine, ok that’s good. However when I tried https access I was always getting this error: “The network logon failed. (1790)“
Searching, I found a few people had seen this problem too but no-one seemed to have managed to solve it, save for a few. They chose to relax security and terminate SSL at the ISA server, and allowed the rules to connect back on port 80. That works but it’s not secure and I’ve seen link translation weirdness doing that in the past. So what’s the fix?
Well I found that if you put the wildcard certificate on the SITE as well as the listener, things start working. Just don’t ask me why! I think it’s probably an IIS thing, I’m just not sure. So don’t follow the guidelines ‘quite’ as explicitly and you’ll get there! And please let me know if this helps you or not, I’d love to know.
Found this helpful article today: Link translation causes an endless loop when you use Web servers that redirect HTTP requests as HTTPS requests in ISA Server 2006
We weren’t getting the endless loop because we were redirecting from http://website/ to https://website/path1 but ISA was still being a real pain in the gluteous maximus and changing the redirection link to http.