I’m getting my first SSL cert and have to specify whether the cert is for https://mydomain.com or https://www.mydomain.com. I’m guessing there’s a signifant difference buried in that choice somewhere, but have no idea what it is. I’d sure like to avoid “painting myself into a corner.” Can someone point me to something that would help me understand the implications of the choice I make?
Thanks,
Bill
Bill Walton said the following on 03/02/2007 12:16 AM:
I'm getting my first SSL cert and have to specify whether the cert is for https://mydomain.com or https://www.mydomain.com. I'm guessing there's a signifant difference buried in that choice somewhere, but have no idea what it is. I'd sure like to avoid "painting myself into a corner." Can someone point me to something that would help me understand the implications of the choice I make?
You are correct to be concerned. The lack of ability of X.509 to deal with 'aliases' and to interpret DNS and other directory information is a known shortcoming and problem.
Most hosting services off the ability to alias the two URL forms - this is easy with DNS. From an end users point of view they are the same. Browsers will convert "mydomain" into "mydomain.com" and "www.myomain.com" transparently for the user even if DNS does not do the aliasing. But the roots of X.509 are tied up with the ISO-RM which was rather antagonistic to the IETF IP model. Its addressing structure was "prescriptive" and if not actually authoritarian then highly paternalistic (aka 'we know what's good for you and you should do it this way!'), so this user convenience did not exist.
You could, of course, bind to an IP address, but that limits you in other
ways 
So you are left with two solutions.
a) but a cert for each "domain" and don't do DNS aliasing but have, in effect, two sites that use the same database
b) pick one as the 'real one and set up the DNS for the other to point to a page that redirects to the real one
While about it, write to the IETF and tell them that you're annoyed that X.509 doesn't support aliasing and throw your support behind the groups that are working to address this matter in future releases.
Hi Anton,
Anton Aylward wrote:
Bill Walton said the following on 03/02/2007 12:16 AM:
I'm getting my first SSL cert and have to specify whether the cert is for https://mydomain.com or https://www.mydomain.com.
You are correct to be concerned. The lack of ability of X.509 to deal with 'aliases' and to interpret DNS and other directory information is a known shortcoming and problem.
Sorry to be so dense. Like I said... first-timer. I may be missing other stuff too, but after thinking about it, my primary concern at this point is about my desire to put parts of my app under SSL and to leave other parts unsecured.
For example: www.mydomain.com - unsecured www.mydomain.com/create - all methods in the create controller under SSL
My understanding was that I could just put a before_filter on the controllers I want to have secured so that any request to, for example, http://www.mydomain.com/create/ would actually go to https://www.mydomain.com/create.
Is that right? And if so, is one of the choices I'm being given (this is on a hosted VPS account with private IP) going to handle this better than the other?
Thanks very much for your help.
Best regards, Bill
Use the ssl_requirements plugin for this. You can specify which actions should be run through https.
As far as the ssl cert, you can always buy a wildcard cert if you want all options open. Otherwise buy www.mydomain.com and save some money.
Hope this helps.
Hi Zack,
Zack Chandler wrote:
My understanding was that I could just put a before_filter on the controllers I want to have secured so that any request to, for example, http://www.mydomain.com/create/ would actually go to https://www.mydomain.com/create.
Use the ssl_requirements plugin for this. You can specify which actions should be run through https.
>
As far as the ssl cert, you can always buy a wildcard cert if you want all options open. Otherwise buy www.mydomain.com and save some money.
Hope this helps.
Thanks, Zack. That was exactly the info and advice I was hoping for.
Best regards, Bill
I'm getting my first SSL cert and have to specify whether the cert is for https://mydomain.com or https://www.mydomain.com. I'm guessing there's a signifant difference buried in that choice somewhere, but have no idea what it is. I'd sure like to avoid "painting myself into a corner." Can someone point me to something that would help me understand the implications of the choice I make?
You could also get a wildcard certificate...
I'm sure other providers have them as well, not endorsing rapidssl necessarily.
Using a wild-card certificate means that there is no means to identify the host you are connecting to is the host you intend to connect to.
Speaking as someone who makes his living in the security world I would say that this invalidates so much about what TLS/SSL was designed to do.
Would I trust a site that uses one? No.
Philip Hallstrom said the following on 03/02/2007 11:19 AM:
Ehm, wildcard SSL certificates are valid for a specific domain and all sub-domains of that domain.
So, for instance, I can secure...
mydomain.com www.mydomain.com store.mydomain.com webmail.mydomain.com etc...
... using one wildcard SSL certificate. The padlock still shows up and it's a secure solution -- no doubt about it.
They are a little more expensive but I think they definitely have their place on a site that partitions functionality under certain sub- domains (see: logical).
Correct me if I'm wrong because I've been shopping wildcard SSL's for the past couple days and am likely to purchase one soon.
Indeed, you can secure all the subdomains with a wild card certificate, but you can't be certain which host in the domain you are connecting to
ChristianBooksForSale.mydomain.com YourFavouritePorn.mydomain.com
This may not matter to you but it will matter to th customer. Heck, it may matter to you if the customer gets upset about it or
The padlock showing up only says that a SSL connection been established. You could do the same thing with a self-signed certificate.
From the vulnerability POV you have a common failure mod; an attacker only needs to subvert on certificate and he has the whole domain. This means you have a 'weakest link in the chain situation'.
Suppose you put the same certificate on a "test server" and on your main production server. The security from the SSL server authentication for your main server will depend on the security on your test server.
You've in effect multiplied your risk.
The history of attacks is that the attackers don't try for the (established) connection. Its much easier to subvert the machine in any number of ways. My newsfeeds tell me of more and more each week.
If cost is an issue, you may wish to investigate Reverse Proxying with a single external certificate and multiple internal certificates (either self-signed or issued from an internal CA).
Chris Grant said the following on 03/03/2007 02:52 PM:
Andreas Schwarz said the following on 03/03/2007 06:06 PM:
Anton Aylward wrote:
Suppose you put the same certificate on a "test server" and on your main production server. The security from the SSL server authentication for your main server will depend on the security on your test server.
So you would buy a certificate for a test server? That doesn't make any sense.
Right. but when you buy a wildcard cert that's what you've done. You've bought a cert for EVERY machine in your domain.
Including the ones you haven't secured.
Andreas Schwarz said the following on 03/04/2007 07:38 AM:
It doesn't make any sense to use the key on a test server - a self-signed key is sufficient for testing - so even if an attacker manages to break into the test server, he still needs to break into the main server to steal the key.
True, bit you're missing the point. The wildcard covers your whole domain.
Once on the test server an attacker can use that as a platform to gain more information and launch other attack. He's "inside" the 'ring of protection' now. His view of what's valuable and your view may differ. He may not be out to steal your cert, he might want to use your platform to run some 'bot to carry out a DDoS on another site, act as a site for some phishing expedition, store warez, store child pornography for a ring, act as a store/server of material that is violating copyright such as movies or songs. Who knows. Whatever: its your loss, your cost - perhaps legal cost proving you weren't culpable. Maybe the DMCA police cart off your machine & software and you have to institute legal action to get it back.
All this has happened out there in the real world.
You are right that in theory it increases the risk a little bit, because the attacker has to use the main server only for stealing the key, not to set up his evil application, but the whole thing is still a rather far-fetched scenario.
All attack models seem far fetched to the site owners, I've found, until the hackers come along and demonstrate more creativity and ingenuity than we expected. That has been the consistent history of network and host security. "I didn't think they could do that" - but they did!
The point isn't that about what you think possible but that that you've opened up a whole new set of avenues without instituting specific controls to address them.
There is always a tradeoff between security and cost/effort, and I think using a wildcard certificate is a good tradeoff.
Your decision. It seems far removed from your original issue.
Andreas Schwarz said the following on 03/04/2007 08:19 AM:
Anton Aylward wrote:
True, bit you're missing the point. The wildcard covers your whole domain.
Once on the test server an attacker can use that as a platform to gain more information and launch other attack. He's "inside" the 'ring of protection' now. His view of what's valuable and your view may differ. He may not be out to steal your cert, he might want to use your platform to run some 'bot to carry out a DDoS on another site, act as a site for some phishing expedition, store warez, store child p0rnography for a ring, act as a store/server of material that is violating copyright such as movies or songs. Who knows. Whatever: its your loss, your cost - perhaps legal cost proving you weren't culpable.
Er... and what's this all got to do with the certificate?
Do you think that in order to get the information or subvert the protection offered by the certificate an attacker will do a head's on attack on the cert? No Way! Most attacks and subversion are step-by-step going for back door or weaknesses elsewhere and using them as a springboard.
All the certificate does is encrypt traffic. It doesn't protect your site. In particular it doesn't protect your site from any problem that might plague a web service or a server or a machine connected to the Internet.
If you do have traffic or transactions that you want to protect you'll need more than a certificate! What you'll need will depend on many factors; how you've coded, specifics of your network ... Wildcard certs are like wildcards in DNS, they can produce some unexpected side effects. Incidentally, do you have complete _and_ _sole_ control of your DNS?
Andreas Schwarz said the following on 03/04/2007 08:18 PM:
server or not. Without the secret key the attacker can't do anything.
Not so. If the attacked can subvert any machine in the domain he can do things that neither of us can guess a and are limited only by his skill.
It has nothing whatsoever to do with getting the key.
So in most cases the security advantage of a seperate certificate for each subdomain is really irrelevant.
Only if you apply the same security policy to all - which you are doing explicitly with the 'shared' cert.
This gets back to much earlier in the discussion, before the wildcard 'shared' cert came up.
What are you trying to protect? The SSL link - which is all the cert allows you to protect - is a transient thing. There is a long history of "SSL Enabled" sites being subverted and the information that goes over the link obtained without cracking the crypto.
As I said, attackers rarely attack head on.