Scott Hanselman

Some Trouble with Wildcard SSL Certificates, FireFox and RFC2818

March 20, '07 Comments [11] Posted in ASP.NET
Sponsored By

When working on a non-finance website recently, the client wanted to include the username as the subdomain, to give the user more of a sense of "my site." So, Fred gets as his address.

The client purchased a very expensive (US$500) "Wildcard SSL Certificate" for https://* and it works fine.

Some trouble happened when a staging site was introduced. Now we're looking at for the URL.

This works fine in FireFox 2 as seen in this screenshot:

But IE7 really doesn't like it. Your first reaction might be to get mad at IE7, "those jerks! They never follow the spec."

However, according to RFC2818 with emphasis mine (Thanks Eric Lawrence!):

Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., * matches but not f*.com matches but not

When I visit * with IE7, it works fine, per spec.

My conclusion here is that FireFox 2 is out of spec with RFC2818. I wonder if this is known by the FireFox team? Am I missing something?

In our case, we'll need to either have wildcard certificate that covers both * and * (the latter in the SubjectAltName field).  If a CA won’t issue us such a certificate for whatever reason, we'll need to buy two different wildcard certificates ($$), and also host on a different port or IP address, since the Server Name Indicator TLS extension is not broadly available at this point, and hence you cannot reliably use two different certificates for the same endpoint. Again, thanks to EricL for helping explain this.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Tuesday, 20 March 2007 23:10:58 UTC
This is just more proof that web certificates are more complicated than I ever want to learn. My hierarchy of pain goes something like:

(in levels of increasing pain):
* Website layout (CSS)
* Javascript debugging
* linux
* web certificate anything
* x86 assembly
* public speaking

As you can see, web certificates score pretty high on the pain scale, and as I learn more about them, they continue to rise in the ranks!
Peter {faa780ce-0f0a-4c28-81d2-3
Wednesday, 21 March 2007 08:42:35 UTC

Out of interest, how did you go about creating the subdomain per user through code?

I want to do this for an upcoming project, but I have no idea where to start. I'll be using .net 2.0 and IIS 6 - am I reduced to monkeying around with IIS with WMI or something?

Any pointers would be really appreciated.
Wednesday, 21 March 2007 08:48:32 UTC
Actually, you can't put a wildcard in the SubjectAltName field. RFC 3280 specifies that the subjectAltName MUST be in RFC 1738 format, which does not allow wildcards.

Wildcards are a real hack anyway. The proper solution would be to get the CA to issue you a CA certificate with NameConstraints set to "", so you could issue your own certificates for the subdomains.
Wednesday, 21 March 2007 09:33:26 UTC
Scott - RFC 2818 appears to be a best practices memo and not an explicit specification so compliance with it would be less clear cut - advisable\desirable but not mandatory. Rasmus Faber's comment that RFC3280 requires the subjectAltName MUST be in RFC 1738 format is not obvious to me - that only applies if the subjectAltName is a URI although it is equally specific about other subjectAltName forms being unique. That said RFC 3280 does say about wildcarded subjectAltNames that "Applications with specific requirements MAY use such names, but they must define the semantics". Given that it seems that RFC 2818 is the best "standard" to follow though even if it isn't a real standard. That probably does reflect the point that Rasmus made - wildcards are a hack and his recommended approach is much better if it is practical.
Joe Mansfield
Wednesday, 21 March 2007 13:38:27 UTC

My company has purchased and used wildcard SSL certs on several of our web sites. I would agree, Firefox is not following the RFC and more then likely you'll have to purchase a second wildcard SSL cert to use the subdomain.

I assume you're using IIS to host the web sites, here is a little know secret - you can configure IIS to handle SSL certs with host headers. Here is a TechNet article with some information:

Hope you find it useful.
Wednesday, 21 March 2007 16:56:26 UTC
So, your index page builds the links for cities (whatever) tagged onto the front of your domain name:

Then your dynamic "return everything you want about this city" page, which is set as the default page in IIS graps whatever URL is coming in and checks what is on the front. Not sure, but the code below might not display correctly in Scott's dasblog. I, myself, am going to switch over to URL rewriting (as per Scott's previous blogs) to get this: Why? Becuase search engines frown on subdomain prefixes that are only one page worth of stuff.(I could be crazy).

Private Sub sSetCity_Production()
Dim strSite As String
strSite = Request.ServerVariables("HTTP_HOST")

'strSite = strSite '.ToLower
'NO CITY SUBDOMAIN, NEED TO GO TO index.aspx to choose a city
If strSite = "" Or strSite = "" Then

End If

If Not Request.Cookies("CityName") Is Nothing Then
strSite = Server.HtmlEncode(Request.Cookies("CityName").Value)

If Left(strSite, 4) = "www." Then
strSite = Right(strSite, strSite.Length - 4) '
End If

strSite = Left(strSite, strSite.IndexOf(".")) 'CentralCoast

End If

Dim conn2 As New SqlConnection(f1.fUseThisConnection(Server.MachineName))
Dim strSQL2 As String = "SELECT CityID, CityName, StateName, CityNameDisplay FROM zJohn.tblCities "
strSQL2 = strSQL2 & " WHERE CityName ='" & f1.stripInjection(strSite) & "'"

Dim cmd2 As New SqlCommand(strSQL2, conn2)
cmd2.CommandText = strSQL2
Dim dr2 As SqlDataReader = cmd2.ExecuteReader(CommandBehavior.CloseConnection)

If dr2.HasRows Then
Session("CityID") = dr2("CityID")
Session("StateName") = dr2("StateName")
Session("CityName") = dr2("CityName") 'NO SPACES
Session("CityNameDisplay") = dr2("CityNameDisplay").ToString 'SPACES LIKE "Central Coast"
'EXAMPLE: CentralCoast IN URL, Central Coast in database

conn2 = Nothing

conn2 = Nothing
Response.Redirect("index.aspx", True)
End If

'End If

End Sub
Wednesday, 21 March 2007 16:58:40 UTC
oops, I forgot to quote Andrew's comment about how do create/use subdomains:
(you also have to put a wildcard(*) in IIS's domain name thing)

<Andrew asked>

Out of interest, how did you go about creating the subdomain per user through code?

I want to do this for an upcoming project, but I have no idea where to start. I'll be using .net 2.0 and IIS 6 - am I reduced to monkeying around with IIS with WMI or something?

Any pointers would be really appreciated.
</Andrew asked>
Wednesday, 21 March 2007 19:09:52 UTC

Check out this article on dynamic subdomains: Code Better
Wednesday, 21 March 2007 20:56:25 UTC
It might be easier to do it like this:

Then you only have to do one certificate and you can map it however you want in IIS.

This might not fit for you though if you want * and * to resolve to two different IPs using just two wildcard DNS entries. using my method you have to have individual *-staging entries in DNS if you want it to be different than *
Wednesday, 21 March 2007 21:47:49 UTC
Thanks John and Eric!
Thursday, 22 March 2007 16:27:23 UTC
Just thinking, but what happens to just plain requests for .htm files? All this stuff has to happen at a very high webserver level to detect and deal with, no? Kinda like really good URL writing is an ISAPI filter, not a .NET interception? (I could be crazy).
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.