Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Assuming this will be done with your own PKI, and not a public trusted CA.

Considering that *.sub.domain.com is valid, and so is *.domain.com is valid, is it technically possible to issue *.com and even a *. certificate?

The certificate I'm investigating is a "*." certificate being used for any other domain name such as "https://google.com" and then performing MITM attacks.

Will any certificate validation framework support a *. certificate? Will it be rejected outright, or will normal validation rules apply?

share|improve this question
    
By "support", do you mean "is accepted" or "is accepted and matches every possible domain name"? –  curiousguy Jun 13 '12 at 22:05
    
@curiousguy - updated... does it result in every possible match? –  makerofthings7 Jun 13 '12 at 22:08

2 Answers 2

up vote 4 down vote accepted

From RFC-2818 - HTTP Over TLS:

Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.

So I believe it would be possible to do something like have a certificate that matches a very wide variety of URLS: *.com, www.*.com, and ssl.*.com. You may want to try double-wildcard certificates (e.g., match *.*.com), but most browsers will not (and should not) accept them.

I also would not be the least bit surprised if modern browsers disallowed wild cards in the next level down from top level domain (e.g., *.com).

share|improve this answer

It is technically possible to make a certificate which contains a name "*.com" but, as per RFC 2818 (section 3.1), a wildcard matches one domain component, not several (i.e. it would be valid for "example.com" but not for "www.example.com"). However, there is a difference between the specification, and what implementers do of it. There are reports that some browsers accept to match a wildcard with several domain components (i.e. "*.example.com" matching "sub.www.example.com").

Moreover, most modern Web browser include failsafes, which reject overly broad wildcard certificates. See this question: "*.com" and even "*.co.uk" will be refused by browsers, even if RFC 2818 would not have seen any problem with that.

share|improve this answer

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.