Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 11 down vote favorite
1

When I open https://java.com my browser says “untrusted connection” but when I open https://www.java.com my browser says it’s ok. But it's the same site.

So my question is: Is this a security bug? It's like having self-signed certs? Several domains struggle with correct HTTPS settings regarding having the "www" prefix or not.

share|improve this question
4  
You could change this to be more accurately: Incorrect use of certificate – Rory Alsop♦ May 10 '11 at 14:08
@Rory, that is strictly true, however I think this is more of a "user perception" type of thing - and for regular users, IF they happen to know/care about HTTPS at all, it looks like a problem with HTTPS. – AviD♦ May 11 '11 at 10:37

3 Answers

up vote 27 down vote accepted

Have a look at the actual error message:

Certificate is only valid for www.java.com.

It is a server misconfiguration. But in this case this is not a direct security issue because both domains belong to the same company. (It is an indirect one because it teaches people to ignore this kind of error message).

Background

What happens here is this:

  • You told your browser to visit java.com
  • But the server answered: I am www.java.com (without aliases) and here is my certificate to prove that.

But your browser does not want to talk to www.java.com, it was told to connect to java.com.

If both domains are not under the control of the same people, this is an issue (think of <something>.dyndns.org):

The connection is encrypted just fine, but you had a secured connection to the attacker. The attacker would then read and possible modify it before passing it on to the real server. When the attacker gets the answer, he can again read and modify it, before he sends it to you. This is called a Man in the middle attack.

Therefore this warning is important in the general case.

What to do?

To be on the safe side you should do this: Look at the domain in the error message. If it is likly that the domain is a valid destination for where you wanted to go (e. g. added or missing "www"), type that domain into the address bar. Do not copy it because some special character may look like valid characters, so you could end up elsewhere on a phishing side.

share|improve this answer
7  
You get a big +1 for "…because it teaches people to ignore this kind of error message". Users should only be told of errors when something erroneous happens (and there's nothing the developer can do about it). – Graham Lee May 10 '11 at 9:30
Really they should resolve to different IP addresses, and have everything sorted out with appropriate use of routers. That rarely happens. The protocol is being extended so that the client can specify which host name it is trying to connect to before the server commits to offering a particular certificate. – Tom Hawtin - tackline May 10 '11 at 11:23
4  
@TomHawtin-tackline "Really they should resolve to different IP addresses, and have everything sorted out with appropriate use of routers." www.example.com and example.com probably are the same site, why would you use two IP addresses? A certificate with both names should be fine. – curiousguy Nov 6 '11 at 2:03
up vote 6 down vote

The SSL certificate for that site is for www.java.com, so your browser is correctly telling you that it doesn't match the domain java.com. It's not a security bug, as security is not compromised, but it's a usability issue -- they ought to have a redirect from java.com to www.java.com.

share|improve this answer
3  
good example: linuxfoundation.org & linuxfoundation.org - But I still think it could be a security bug, because the users just click the: "yes, accept cert, etc." - they will not read that it is a self-signed cert or just a misconfigured server that doesn't has correct redirect... – LanceBaynes May 8 '11 at 19:19
up vote 2 down vote

The certificate should either have a "Subject Alternative Name" or be a Wildcard to address this particular issue. Here is a SAN example

enter image description here enter image description here

Many issuers will configure a certificate this way. In your particular example, Sun Microsystems has a private issuer that is responsible for this this certificate. That server neglected to add the common SAN names in the request.

You say there several domains that struggle with this issue. Take a look at the issuing CA, and if it's private or is common among several problem sites, then the administrative practices are likely to blame.

share|improve this answer
"The certificate should either have a () or be a Wildcard" Is the use of *.example.com for example.com standard? – curiousguy Nov 6 '11 at 2:04
@curiousguy Yes it is standard for a cert to also alias the root and www site. most registrars should do this. I added some screenshots to help – makerofthings7 Nov 6 '11 at 9:05

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.