Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Ok, my scenario is interesting. What I want to do is create multiple subdomains for a give url. For example subdomain1.domain.com and subdomain2.domain.com. I plan to buy an SSL certificate that convers unlimited subdomains for domain.com. However I don't want these to appear as subdomains, I want to give them each their own url. For this I plan to use url masking. Which means that at any given time you could visit the subdomain address and see the same content displayed as you would it's respective domain name that's masked on top of it.

I know that the other domain names themselves will not show the SSL cert, however will the data still be secure considering it's actually on a subdomain that is SSL certified? Remember it's only url masking.

Is my logic correct that it will be even though it doesn't show that it is? I mean if you visit the subdomain1.domain.com you would see the cert. But just not if you visit its respective masked url.

share|improve this question

migrated from stackoverflow.com Jun 13 '11 at 15:35

This question came from our site for professional and enthusiast programmers.

add comment

2 Answers

You'll find that "breaking SSL" for domains for which you don't have a certificate is a feature, not a bug.

If you want to have one certificate for multiple host names, there are two approaches:

  • wildcard certificates, but their usage is discouraged,
  • multiple Subject Alternative Names (one for each host) in the certificate.

If you can get a certificate for the number of domains you wish to mask, you may also be interested in doing the "URL masking" as a reverse HTTP proxy, locally on your server. This approach may also give you more flexibility if you need to expand to other domains with other certificates (provided you have multiple IP addresses or can use SNI, then).

share|improve this answer
add comment

Ok to answer my own question, with a little research I've discovered that domain masking actually breaks SSL encryption. That really sucks. Because now I don't know how I'm going to secure thousands of domain names inexpensively. How do hosted e-commerce sites do it?

To make matter worse, I need to maintain sessions across these various domain names which means they pretty much have to be masked subdomains of one main url.

Man the internet is not set up for what I want to do. If only domain masking didn't break SSL.

share|improve this answer
1  
Some hosting providers use a single domain for encrypted traffic...you'll often see this with low-end e-commerce sites, where you start browsing at www.example.com but then end up at securehost.provider.com for checkout. Otherwise, you factor the annual cost of a certificate into your hosting fees. –  larsks Jun 13 '11 at 16:07
    
This is not going to work for us because we want the entire experience to be secure do to firesheep session hacking. Basically we're building a hosted e-commerce solution where people only need one log-in and can browse thousands of online shops, each with their own domain name hosted on our servers. So they all have to be HTTPs secure and we have to maintain sessions across the whole network. Which means they have to be masked urls, because sessions can't cross domain names. –  roxics Jun 13 '11 at 17:00
    
The only solution I can think of of is using an iframe. Where the actual secured site subdomain1.domain.com is pulled into an iframe on a website with a domain.com url that is just one big iframe. I assume that url would need it's own SSL cert. But I also assume that cert doesn't need to match the one for the main site??? This would allow sessions to remain in tact, as the user is only browsing the subdomain of the main site. Then we would just need to use some kind of code hackery to duplicate the extension of the url on the domain.com to match that of the subdoamin. ie. /merch/product1 –  roxics Jun 13 '11 at 17:06
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.