Wednesday, March 12, 2008

Multiple SSL Sites on a Single IIS Server Using Host Headers

Wildcard SSL certificates can allow you to publish multiple IIS web sites--all using SSL on port 443--that are accessible by host headers. That is, if you're running on IIS 6 or above.

So you read about these things, wildcard certificates, but mostly you read about how to buy them. It is possible (and easy) to create one for yourself, however, so long as you don't mind it not being trusted by folks' browsers. There are some really good uses for these, not least in a test environment in which you don't care about the trust. 
Production environments need them, too, sometimes, such as when you're using a network appliance like a Netscaler or F5 load balancer. Those devices allow you to point multiple URLs (cnames, really) to a single (or multiple) server(s). Very handy.
In our case, we have several web sites that we'd like to secure using SSL. Problem is: they're all on a single server. There are several options for dealing with such a case: assign multiple IP addresses to the server, use different SSL ports for each IIS site, or (definitely the coolest option) use a wildcard certificate on the server to allow IIS to decipher the http host header. This option, by the way, is a new feature with IIS 6, so if there's anyone out there still using IIS v5, this is another reason to upgrade.

A little background on the problem might be in order: a SSL certificate is used to encrypt the http data. Normally, in setting up a IIS web site, we differentiate that site from all the others by assigning unique host headers to each site. IIS can use those host headers to determine to which site to route any given http request.
When the site is using ssl, however, the host header is encrypted, which introduces something of a chicken-and-egg thing: since the host header (along with all the rest of the data) is encrypted, IIS can't use that to determine which site to send the request to. And, since a SSL certificate is site-specific, IIS can't use a certificate to decrypt the data until it knows which site the request belongs to.
Thus, it widely is reported that it isn't possible to have multiple SSL sites on a single server, all sharing the same port. Enter wildcard SSL certificates and secure server bindings.
The wildcard certificate allows IIS to use the same certificate for all of the sites on a particular port. That takes away the requirement that IIS know which site's certificate to use in decrypting the data.
Secure server bindings help IIS in securing the wildcard certificate, a requirement for setting this up.
Note that a similar solution is available to apache. You can read about it here.
Thus, it is very possible to have multiple SSL sites on a single server, all sharing the same port.

Configure your sites to use host headers
Host headers are the backbone of this. Open the properties window for each site in IIS and click the advanced button. There, you can add the appropriate host header on port 80.

Creating a self-signed wildcard SSL certificate
The next step in this process is to make sure that all of the relevant sites have the same SSL port assigned to them.
In IIS, go to each site's properties and enter the appropriate port number (the same one for each site) in the SSL Port field. 443 is the default SSL port.
Note that once you do this, all but one of the affected sites will stop. That is because, at this point, IIS isn't configured to allow multiple sites to share the same SSL port. 
That's OK; we'll take care of that in a moment. 

Now, to generate the certificate: using SelfSSL, generate the certificate for one existing IIS site.
SelfSSL is a tool that's a part of the Microsoft IIS Resource kit.
If you haven't downloaded and installed it, you'll need to do that first.

Here's the syntax:
selfssl /n:cn=* /s:1 /P:443 /v:3650
Where * would be your own URL. So if you had these sites: 
you'd use this code:
selfssl /n:cn=* /s:1 /P:443 /v:3650
It's the * that makes it a wildcard certificate. 
The /s:1 is the site identification. There are a variety of ways to view a site's identifier, but the easiest simply is to open the IIS manager and click on the "web sites" tree on the left. The right-hand pane will show the description and identifier. The default site has an identifier of 1; the other sites have very long identifiers. 
/P: is the SSL port you're using, and /V: is the number of days for which this cert is valid. Why would you want it to expire, anyway? 
 Now you've generated a wildcard certificate. 

Assign the Certificate to your sites 
 The easiest way to assign a certificate to a site, having already created it, is to view the site properties in IIS Manager. 
Click on Directory Security, and then on the Server Certificate button. This will start the wonderful wizard of IIS. You already have created a certificate, so when the wizard prompts you, choose "Assign an existing certificate." When you click next, you'll see a list of available certs, including the wildcard certificate you created. 
Select this certificate, click next, and make sure you assign it the same port that was assigned to the first site.  
That's it: once the wizard has finished its magic, you've assigned the cert to your site. Repeat this for all of the sites you want to secure on this port with SSL. 

Configure Secure Server Bindings 
 This is the final step. It involves running a vbs script to set up secure bindings, which allows IIS to use host headers with SSL and secure the new wildcard certificate you created and installed. 
 The syntax is like this:
cscript adsutil.vbs set /w3svc/844934796/SecureBindings ""

The adsutil.vbs script, at least on my systems, is at C:\Inetpub\AdminScripts. You'll need to run the script command from that location. 
 The syntax breaks down like this: 
844934796 is the site ID. Substitute your own site identifier there. 
443, again, is the port is the host header for the site. 
Make sure that you have this host header configured in the site properties in IIS, as well. 
Run this script for each of your IIS sites. That should be all you need to do. 

Start up the stopped sites after you've run cscript, and you should be good to go. 
 Microsoft has a few documents that run through this, but they don't really put the pieces together for you. Here they are: Configure SSL Host Headers (IIS 6.0) Configuring Server Bindings for SSL Host Headers (IIS 6.0) Obtaining and Installing a Wildcard Server Certificate 

 By the way: if you've done a lot of testing, and you've generated a bunch of certificates you're no longer using, you can delete them. Run mmc.exe and add the certificates snap-in. You'll want to choose the "local computer" version. Using that, you can manage all of your local certificates, including deleting the ones you no longer need.


  1. Great post - thanks very much!

    Had been searching for a decent set of instructions on setting up SSL host headers... and finally found 'em here.

  2. I am struggling to find this information from last few days.

    thanks you very much for the article especially for the title of the article.

  3. Hi Lane,

    Great post... but what if I have different certificates for all of my sites and I want to run them on one IIS? will it be still possible?


  4. Hi, Mohit. The answer is: sortof. If you've got separate certificates for each site, then you can't use the the same IP address for each site. So you'd have to assign a separate IP address for each.

    The problem is that IIS has to use either the host header (which is encrypted) or an IP address to determine which site is getting the request. If you've got multiple certificates and are using SSL, it can't determine which certificate to use, so you're left with using multiple IP addresses, instead.

    Incidentally, I've run across--but not used--a free software load balancer called "Pure Load Balancer." ( I've no idea how well it works, but it's intriguing: we use a Netscaler load balancer front-end on all of our public-facing web sites, which gives us a lot of flexibility in how we configure the actual web servers. Unfortunately, these devices are quite expensive; I'm curious to see if something like this would offer some similar benefits to oufits with fewer resources .

  5. Thanks for the reply, Lane. I was trying to avoid using multiple IP address solution, but it seems there is no other easy way around...

  6. I'm afraid that's true. Now, if you *do* have access to something like a Netscaler appliance, your options are opened up some; with these, you can create multiple CNames that point to the appliance, which can, in fact, parse out the correct site and send it on to your web server. But short of that, yeah: it's multiple IP addresses.

    I would be interested if someone has had any experience with the software load balancers out there: is this possible with some of them, as it is with the hardware appliances?

  7. Hi Lane,

    I see that the examples are for using child domains with the same parent domain name. Is there a way I can use this wild card certificate with different domains altogether? like:,,

  8. Babhuman, the short answer is: yes, you can; you can use any single certificate for any web sites on a server. But, if the name on the certificate doesn't match the server name, you'll get warnings and errors in your browser. It'll work, but the experience could be ugly.

    There's another option for generating a certificate with Alternative Names ("Subject Alternative Name" or "SAN" is the term) that can reflect multiple DNS names. Basically, it's another field on the certificate that lists the alternative names by which the server can be known.
    To do this, though, you have to use something besides SELFSSL; it doesn't appear to support generating certificates with SAN entries.

    So you'd need to use a CA (certificate authority) to generate the certificate. is a good free option for getting a certificate that would meet your needs ( They do no checking on the validity of a certificate request, so trusting them as a root CA could be dangerous, but for the types of uses for which you'd use a self-signed certificate, they're quite good.

    You also can configure your Windows server as a CA, and make your own certificates. This is a good instruction site for doing that:

    I hope that helps!

  9. This comment has been removed by the author.

  10. Hi Lane,

    I currently have a secure site using digicert certificate and I would like to add another secure site on the same IP, but on different port (8043). Would I need to obtain a domain name for the new site? Since it will be a private site, I didn't think that would be necessary. I tried to use the same certificate as the first site, but have not been successful. When running the new site on remote machines, it's unable to display as error says unable to open page because the server stopped responding. When running on the web server hosting the site, it says the certificate already been used by another site and I have to click on link to trust the certificate. The certificate does list the IP as one of alternative names. Do you have solution for this? Thanks.


  11. Kyle, I think some of this is going to depend on how Digicert set up the certificate.

    The short answer is yes: you can have a single certificate for multiple sites in IIS. They may or may not work as you need them to, though.

    Try this quick experiment, which might get you going:
    in IIS manager, right-click on the site that already has the certificate installed (and working) and select properties. Then click on the dir security tab and then on the "server certificate" button. After the first screen in the menu are some options (renew, remove, replace, export, and copy). See if export is enabled. If it is, you should just be able to export that certificate to a .pfx file and then import it in to your other site.

    If it's grayed out, it was installed as "not exportable". If that's the case, you might have to get back in touch with the digicert folks, if you want to use this certificate for both sites; they might be able to re-process your certificate request.

  12. An excellent post, would you repeat the process if there are multiple host headers for a site?

  13. Aki, that's right: this will work for as many host headers as you'd like to use.

    If you're using host headers that aren't using the same suffix (that is, that aren't using the "*.servername.domainname" model, you also can set up a single certificate with multiple SubjectAlternativName entries and install it on each site. I've got instructions for that here, if that's useful.

  14. just wanted to say thanks. this was helpful and well written

  15. Hi,

    Great post - this works on IIS 7.5 on Windows server 2008 R2 as well just in case anyone is wondering.


  16. Hi Lane,

    Is it possible to use the same ip address, but different ports? If so, how can this be done?

    Also, i've heard windows server 2003 SP1 makes it possible to use hostheaders with ssl. Do you have any info on this? Does SP1 also require a wildcard cert?

    I'm not using a wildcard cert, i have 2 sites, with 2 separate certs, but i don't want a separate ip address.

  17. Hi, Sophie,

    The short answer is: yes, that's quite possible. In fact, that's what most people have been saying you *have* to do for quite some time.

    If you already have the certificates, you might run into a problem: my recollection is that the certificates reference the port they're supposed to be using, and the default would be 443 for each. To use a different port, you might be forced to get a different certificate.

    But, to answer the question of "how do I do this?", IIS makes it pretty easy:

    Create two different sites in IIS, and configure the SSL port for 443 on one. The other needs to be a different port; a lot of folks use 1443 or 4443, or something like that, but the choice is yours.

    Having done that, you assign the certificates to the sites using the same IIS manager (Web site properties -> Directory Security -> Server Certificate -> Assign an existing certificate).

    That will set up your sites to use SSL on different ports. Do note that the various browsers use the default port of 443 for https traffic; if you set up a site on any other port, the urls to it have to specify that port explicitly.

    I hope that helps! -Lane

  18. Great article, you just saved my day (at least some hours), thanks!

  19. Hi, what I am trying to achieve is pretty simple yet I can't find any clear solution.

    Is it possible to correctly setup multiple TLD domains (, to use their own certificate issued by a CA like goDaddy or Verisign? My setup allows me to use a different IP for each website.

    Thanks for the help

  20. Yes, it's quite possible. In fact, that was the only option up until IIS v6.

    So what you'd do it set up your sites. By default, they'll both be using port 80, and one will be using port 443 for SSL.

    Right-click on one site and select properties.
    Click on the Advanced button next to the IP address field and remove the "Default" listing. Then click on the add button and enter one IP address.

    Now do the same for the other site, but use the second IP address for it.

    Once you've done that, you can configure each site to respond with SSL on port 443.

    Finally, you'll want to install your certificates.
    From the properties menu, click on the Directory Security tab and then on the server certificate button.

    That will open the IIS Certificate wizard, which will walk you through installing each certificate on the appropriate site.

    Let us know if you run into any troubles with that!

  21. Great Post, just what i am looking for.

  22. When you originally configure the host headers for port 80, do you leave the ip addess as "All unassigned" and Default?

  23. Wrexhamlager, that's right: since we're using shared SSL certificates, there isn't a need to change the ports or IP address assignments from the default.

  24. Excellent post. I'm having an issue with being able to run multiple sites on port 443 with different host headers. I've posted what I'm trying to do here
    Any suggestions would be much appreciated

  25. Im having a similar issue with running sub domains off port 443 any ideas. It seem to keep on switching between the sub domains, i have had to use separate ports at the moment but if people have a fix that would really help.

  26. James, do all of the sub domains have the same ssl cert installed? That'd be the first thing to double-check.
    If it's possible, I'd first make sure all of the sub-domain configurations are set up correctly to use host headers without SSL: if one site is hogging all (or some) of the host header traffic, the request won't get routed to the correct site.

    Hope that helps; let us know what you find!

  27. Is there any possibility of using a wild card certificate for 2 SSL site using 2 different port. 443 and 8443. But not having to be port specific in the URL? For example: (point to web app on 443) (point to web app on 8443)

    Thank you!


  28. KK, while you can have a single certificate for multiple sites, when you specify https in a browser without a port number, the browser connects to the server on the default SSL port (443). I think that the only way to get at what you're wanting would be with some creative redirects, and in the end, you'd still have people accessing the 8443 port using the explicit port number.

    I can envision, though, something like this:

    You have two sites that answer on port 443, one to, and one to (on 443) would then redirect to on port 8443. That wouldn't keep you from having the port number show up in the browser URL, but it would keep folks from having to enter it themselves.

  29. Thanks Lane!

    So the only way is if we use port specific URL if we need to direct direct to different port or it's not even possible given that 443 is binded?

    Thank you!


  30. I may not be answering your question correctly, so let me know if I'm missing what you're getting at.

    You can have multiple sites on your server, each using SSL, and each on different ports. That doesn't really have a lot to do with the SSL certificates you use. You do need keep in mind that when someone browses to your site over SSL _without_ specifying a port, the default SSL port (443) is being used, so that is the same as specifying

    What that means is that if you want some traffic to get redirected to another port (in this case, 8443), you have to have some way to differentiate the traffic using host headers.

    I'll stop there for a moment and point this out: you can have and both be separate sites and both use port 443. That's the gist of this post. That is to say: you might not have a lot to be gained by putting the secure site on a different port.

    Assuming you _do_ want to use 8443 for one of your sites, you can either publish a link to it, or you could set up a new site using host headers as described above, such that (on port 443) redirects to

    I'm not sure what benefit you get from having it on a separate port, but that's one way to do it without making people type in the port number.

    I hope that helps, and let me know if I'm not getting at your question right.

  31. Thanks Lane!

    You are explaining it correctly, I'm hoping to use port as a way to filter traffic at the network level as the secure site should only be accessible by machine internal to the company where the other one is available to the world. I hope this make sense. How does the redirecting work?

    Thank you!


    1. Hi, KK. I apologize it's taken me so long to respond; I hope you've got a solution in the meantime.
      In any case, the easiest thing to do is to create a new site as this article suggests and have it listen on port 443, as well. Then you would just put an index.html file in there with something like this in the HEAD section:

      meta http-equiv="REFRESH" content="0;url="

      Folks outside your org would be able to get to the initial index page, but the :8443 page wouldn't be accessible to them.

      Hope that helps!

  32. Hi Lane,
    First let me congratulate you on writing such a great article.
    Now my question - We already have a website running from port 443 from our server, we want to set up another website to use port 443. Now as you explained this is is possible using wildcard server certification. Now my question if when i request for such a certificate, my Certificate team is asking for a CSR (certreq.txt) file. Now my question is from which website should i create this CSR as both the website (one that is running originally and the new website to be hosted) are capable of creating the CSR.
    Or can i create the CSR from either of the 2 websites?

    1. Hi, Anant, thanks for your kind words.
      Since the wildcard certificate will be used for both of the web sites, it won't be a site-specific certificate, so the only important point is that the CSR be generated on the server that will be running both of the web sites.

      When you get that new certificate back (that is generated in response to the CSR), you'll install that certificate on both the new and old web sites using the steps outlined above. If something doesn't go as expected, I'd love to hear about it and see if we can't work out a solution.

  33. Thanks Lane for your responses. i will try that..
    One final question before i try doing it.
    So i have a production website which is already having a SSL certificate (assigned to
    Now i have hosted couple of website on a TEST machine (seperate machine) with host header as and
    I am now going to request a wildcard certificate for test machine with * wild card so that both the websites and can use SSL certificate.
    Just wanted to check if this will in any way impact the production website and certificate.

    1. Ah, good: you're running tests first! That's a step a lot of folks skip; I'm glad you're doing so.

      Any certificates you're using on one server won't affect the functionality on another server, so you shouldn't have anything to worry about with this test. I would work on doing that certificate migration a few times on your test server so that you're comfortable with (a) the process and (b) the effect it has on the sites while you're in the middle of it.

      While it doesn't take a long time to assign the new certificate and run the vb script to set it up so it'll be usable on multiple sites, the order in which you assign the certificate *does* matter: one of your sites will be offline (as we saw in the example above) for that short period, and you'd typically want that to be your new, never-before-published site, rather than your existing, has-been-running-forever site.

    2. Another consideration: do make sure your certificate admins aren't revoking your current production certificate while you're doing this. They're probably well aware of how that works, but you could end up with users getting a pop-up warning if your org is publishing a certificate revocation list.

  34. Brilliant..your replies are comprehensive and already answers questions which i would have asked . I will ask my team to create the certificate for the TEST machine and keep you posted how my experiment goes.

  35. While my internal team is creating the certificate i have another question.
    The certificate that i have requested now (for both the SSL websites) has client and server authentication enabled to it.
    Out of this 2 website - 1 is a public website (with access to everyone) while the other is a web service (with limited access).
    Do you think it's possible to run 2 website one with client authentication enabled and other with client authentication disabled (even though the certificate has client / server authentication enabled to it)?

    1. Hi, Anant,
      I believe that what you're describing here will work; I can't think of a reason it wouldn't. If I'm thinking of the right piece of this, you're essentially setting flags on the certificate signifying that it's OK to use it for the various activities. If a site doesn't make use of all of those, I don't believe there are any warnings or errors that will result.

  36. Thanks Lane,
    It seems to be working ok, one more question - the web service hosted currently supports client and server authentication
    Can you please provide me some details on how to generate the client key from the server and use it on client to authenticate?
    thanks a lot.

    1. You're using the certificates MMC plug-in for generating the CSR, right? If so, I believe you can follow the instructions here:

      These are the steps I'd go through if I were in your position, and I *think* they'll meet your needs. (note that I'm not affiliated with UW; they just have a good set of instructions for this).

      Let me know if that doesn't work or if it's unclear.

      Thanks! -Lane

  37. Thanks Lane, I have been tirelessly trying to work this out. Let me explain it quickly what I have done up till now.
    My team has issued 'internal' certificate (wild card certificate) for my TEST environment. I have been given 3 certificate
    1) Intermediate certificate
    2) Root certificate
    3) Internal wild card certificate (with client/server authentication enabled)
    Issued by - XXXXXX Private CA 014
    where XXXXXX is company's name.
    Now i have successfully imported these 3 certificates on the web server with Intermediate and root certificate under 'Trusted Root certificate authorities' using MMC.
    Now I have created the private key (.pfx) file from the IIS.
    When i try to access the website (hosted on the web server) from my machine it gives me the following error. For this website on IIS, i have enabled 'Require client certificate' under Server communication tab.
    '''HTTP Error 403.16 - Forbidden: Client certificate is ill-formed or is not trusted by the Web server ''''
    I am going mad over how to fix this - any help on this will be greatly appreciated and i will buy you a stock of beer.

    1. I feel your pain, Anant. First check would be: which store in the MMC are you using? That is: when you add the certificate snap-in to the mmc console, did you select "My user account", "Service account", or "computer account"?
      The computer account is generally the one you want to use, FWIW. You might try adding your intermediate CA to the trusted root CA store, too, as a test.

  38. thanks Lane.
    Yes i have taken care of both the options i.e. used computer account and added intermediate CA to trusted root CA, but no luck

  39. Thanks Lane,
    One of my developer did the following
    '''disabled the certificate validation at IIS by setting the flag (CertCheckMode="1") '''
    Can you please let me know whats happening behind the scene and whats the implication (if any) of doing this change on production, considering there is another website running along with the web service (that required client / server authentication).
    On the test - it seems to be working fine without impacting the other website but i want to be 100% sure before doing this on production.

    1. Hi, Anant,
      I'm glad it's working in test; that's very good news. The CertCheckMode controls whether the certificate should be validated against a Certificate Revocation List. That is: if the CA publishes a CRL (via URL), should the system check the list to see if that certificate has been revoked? The default (zero) is yes: check the CRL. The value one tells the system not to check the CRL.

      CRLs are something of a security feature that allows for certificates that have been misused, abused, or otherwise a part of something untoward to be revoked by the CA; they're necessary because once the certificate has been issued to the user, there's no way to force the user to return or cease using that certificate. Hence CRLs, whereby clients can check a list of revoked certificates, and if that certificate appears on the list, show an error.

      In your case, I can't see that you'd be introducing any problems by turning off the CRL check. We actually turn that off on many of our servers that don't have outbound internet access but utilize a handful of 3rd party certificates: disabling that has really sped up serving of some pages. We're doing that on the server-side (reg key) rather than on a cert-by-cert basis, which is what you're looking at here, but the effect should be the same.

      AFAIK, there aren't any browsers that (currently) complain about the CRL being disabled, so I don't *think* you should see any bad effects.

      I hope that helps! -Lane

  40. Thanks Lane.
    That justification actually settles my nerves, amazing man ..hopefully will not face any issues while production deployment.
    I again appreciate your help on this matter and will come back in case of any queries, business testing starts from next week so fingers are crossed.

  41. Me again - Everything is working as a charm right now.
    Just one question - whenever i tried running the web service outside my company's network is fails but then i imported the Intermediate certificate and it all works fine. So I have following question
    1) What is the significance of Intermediate certificate and is it okay to share with the consumer of the web-service?
    2) Do i need to share the root certificate also and again what is the significance of this certificate?
    Thanks a lot

    1. Hi, Anant; I'm really glad everything is working well. Well done!
      An intermediate CA is simply a certifying authority that isn't a root. That is: the CA cert is issued by a different authority. There's actually a reasonably accessible discussion of the basics of them here:

      In short, though, yes: the client will need a complete trust chain: if they trust the intermediate CA but not the root CA that issued the intermediate CA cert, you still could--that is, you should, but probably won't--run into some pop-up errors on the client side.

      In any case, if you're going to have to get one cert to the client systems for installation as a trusted entity, you might as well do both that intermediate and the root CA; my hunch is that if you don't do both now, you're likely to have to do it later, so this should save you some time in the future.

      It sounds like this was something of a big project, and it also sounds like it's working out well. Well done! -Lane

  42. Thanks a lot Lane, yes it is massive..finger crossed for prod deployment now.

  43. Hi Lane,
    Another question (on another subject).
    We have a website with SSL certificate with 1024 keystore. Now we need to renew this certificate and the back office can only issue a certificate with 2048 keystore.
    One option is to create a dummy website (on the same IIS server) and provide the CSR with 2048 keystore and ask the team to generate the certificate.
    My question is if we will try to replace the certificate with 1024 keystore with 2048 keystore, will there be any issues?

    1. Hi, Anant,
      You shouldn't run into any trouble with the 1024/2048 keys; modern browsers support both, so unless there's a legacy app using web services that are protected with these keys, I don't think you should have anything to worry about.

      We did, FWIW, run into a problem once with an old application that did some certificate translating and didn't support keys greater than 2048, but that was three or so years ago, and none of our browsers had any difficulty with the change.

      You *will* want to make sure that the issuing CA is trusted by all of the clients, which could be a concern with an apparently changed infrastructure. But that'd be the case regardless of the key size.

      It's probably worth (like all things) testing to be sure you don't have any unexpected hiccups. But I shouldn't expect any problems for basic web services.

      Hope that helps! -Lane

  44. Hi Lane, Thanks for creating this blog!

    We have an SBS2011 server, single static IP and a 5 SAN certificate from Godaddy ("remote" and "extranet" are 2 of the 5 SAN's. RWA and OWA are working fine via using the cert.

    I wish to create a partner extranet site on using SSL with the same certificate but i don't want to break/disturb RWA and OWA. Specifically, i'm afraid of running the script on the "SBS Sharepoint" web app without knowing how to undo the changes if it runs into trouble. Any guidance you could offer on this task would be more than welcome.

    Thanks again..Billybob

    I'm afraid of running the script and breaking RWA/OWA and not knowing how to undo the process? Can you offer any pointers on this?

  45. oops..
    The "" should have been "" and sorry for the repeated section at the end.


    1. Ack. Sorry, Billybob for not responding; I'm sure this is much too late to be useful.

      Nonetheless, for posterity's sake: to undo this, you can simply choose the original (or any other) certificate for the site, and you'll be back to the way things were initially.

  46. Hi Lane,
    Trust you are doing great...finally we had the production deployment today and as expected how much you prepare for it, Things will never work fine in first attempt on production.
    I have a question and i am sure you can help me with this-
    So i have got a wild card certificate for * - Now when I try putting this certificate on (along with another service that i hosted on the same server which is
    Now when i try to run it and accesss - it gives me invalid host name..
    Any idea what can be problem..for my default website I have put the host header as ?

    1. Hi, Anant. Sorry for the delay in getting back to you; I hope and trust that in the month (!) since you posted this. I missed it in the changes here.

      So, the "invalid host name" error that you're getting: is that a certificate error in the browser, or is that a connectivity error (such that it won't bring up the page)? The former is a cert error, but the latter would be networking (or such).

      I'd love to hear how it worked out, and if I can help (more quickly, now!), I'd be pleased to.

  47. Hello,

    I have created the CSR file with * and installed the same in server but i am getting certificate mismatch error. All the links ends with

    Could you please help me in fixing this.



Thanks for leaving a comment!