Keyvan Nayyeri

Older readers can remember my post in the latest days of 2006 that showed how to implement a simple HttpModule to eliminate the “WWW.” prefix from domain names in ASP.NET applications to have unique and shorter URLs for all the pages on a site. Later in 2007 I also wrote a separate post emphasizing on some techniques to simplify URLs on a site and discussed why this technique should be considered by developers in their web applications, and how to use some common mechanisms to accomplish this goal.

Generally, I’m a big advocate of URLs without “WWW.” prefix which is something being supported by many developers out there (Telligenti’s are one of them), and there is also a site dedicated to encourage all developers and webmasters to avoid this ugly prefix in order to to shorten their URLs.

Yesterday and early today Steven Smith and Rick Strahl started a Twisation (the replacement term for “Twitter Conversation” founded by me!) talking about the necessity of that “WWW.” prefix on URLs or not. Steve is also an advocate of this idea, but Rick introduced an issue with SSL certificates as a downside for dropping the prefix. Later I jumped in and continued the discussion with Rick to a point that I thought may be worth sharing for everyone here. I just try to put it together in a single post, so everyone can benefit from the summary and hopefully eliminate that prefix from his URLs.

The problem that Rick had talked about was the fact that when you generate a SSL certificate, you need to enter the domain name and SSL will be valid for that specific domain name, so if you register for a domain with “WWW.”, then you cannot use it without the prefix. In this case you should retrieve two separate certificates for each domain which costs money. Besides, some providers don’t allow you to choose between having the prefix or not, so they automatically generate the certificate name with “WWW.” and things go beyond your control.

As a side-note for those who don’t know what the problem is, if you navigate to a site hosted on secure layer but the SSL is associated with a different name, then you receive a SSL error that you should have seen many times to now. This can be distracting for many clients specifically for more sensitive sites. An example is Rick’s West Wind domain without “WWW.” that generates an error in browsers because the original certificate is issued for a domain name with “WWW.”.

Let’s get back to the original issue. You should know that there are two general types of certificates issued by providers on the web: normal certificates and wildcard certificates. Normal certificates are associated with a specific domain name and cannot be used with sub-domains of that domain, but wildcard domains cover the whole domain and sub-domains as *.domain.com and can be used to secure all parts of a single site. Anyway, wildcard certificates are comparatively more expensive than normal certificates. By the way, I didn’t know about the existence of wildcard certificates and their differences with normal certificates until today!

But what can you do if you don’t want to spend more money on wildcard certificates? In this case you can work with some certificate issuers that are more honest and automatically generate the base domain name when you request a SSL for your domain. I use GoDaddy certificates that are comparatively cheap. One of the important advantages of GoDaddy that I wasn’t aware of is that they generate a certificate for your sites that works with and without “WWW.” prefix without any extra charge and in the single original certificate. To showcase this in action, I disabled the automatic redirects of requests on Waegis, so for a short while you can check out the registration page URL with and without the prefix. I got this SSL for a very cheap price and it’s a single normal SSL, but it works fine in either cases. I think that there are some other providers that do this as well, but there are also some providers that will charge you for these four extra characters! I think this simple point can be a good factor when considering to choose an issuer.

Therefore, to summarize the solutions, I can say that you can use a wildcard certificate or issue two separate certificates that both cost money and may not be a good option for many cases. You can also look for a SSL certificate issuer that automatically includes the base domain name when you generate one for the domain name with “WWW.”.

In the end I would say that I’m not such an expert in this field, so there may be other/better solutions that you can kindly leave as comments for this post. You may also want to let others know if you know an issuers that automatically includes base domain names in its normal certificates.