567193 - Enforce Mozilla CA Policy requirement section 7

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Eddy Nigg (StartCom)]

The Mozilla CA Policy section 7 which calls for the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate which is currently not enforced.

Bug 526560 and other discussions suggest to lay out a plan to enforce this requirement.

Comment 1

[Ben Bucksch (:BenB)]

<http://www.mozilla.org/projects/security/certs/policy/>, Section 7:
> verify that the entity submitting the certificate signing request has
> registered the domain(s) referenced in the certificate or has been
> authorized by the domain registrant to act on the registrant's behalf;

This explicitly asks that the domain is registered.

Internal hostnames like "www", "intranet" or "mail.local" cannot be registered, therefore they are excluded from certified.

So far for the rules, the policy is clear as-can-be on that.

--

This also has security implications: If certs for "www" are issued to anybody, the cert would have no value. If company A gets a cert for "www", person B can get one as well. Assuming person per can intercept wire traffic in company A, person B can then impersonate the server "www" and read SSL traffic in cleartext, without anybody noticing, because person B's cert is valid for company A's server "www".
If you say that person B cannot intercept traffic in company A: That is precisely the scenario that SSL tries to protect from. So the SSL certificate protection is useless, the SSL guarantees do not hold.

Solution:
Use "https://intranet.company-a.com" as internal host (including a cert for "intranet.company-a.com") and let people bookmark it.
That *is* as secure as SSL is.

Comment 2

[Kurt Seifried]

I would say it's very simple:

1) the domain/hostname being used in the certificate MUST reside under a valid TLD, i.e. .com, .co.uk, etc. This also ensures that it is globally unique (as opposed to "company-name.internal" or "www") - assuming a registrar doesn't sell a domain name more than once (who knows...). 

Actually that's about all I can think of for now, if a CA can't establish this then chances are they are doing much if any checks at all.

Comment 3

[Jean-Marc Desperrier]

I'll copy what I said in bug 526560 :
Even if it were considered adequate to issue to certificate for a TLD that is known to be non-public, RFC2606 defines that they are *only* 4 values ".test", ".example", ".invalid", ".localhost" that are actually garanteed to never become a public TLD. Any other choice could become a valid TLD at any point in time.

Therefore, only those 4 values can be safely used for a non-public TLD, which means there's little point in doing it.

Comment 4

[Eddy Nigg (StartCom)]

Jean-Marc, I wonder which protection any of these would give you if your neighbor can get the exact same host name for his certificate too. There is a reason only REGISTERED domains are permitted in the Mozilla CA policy.

Comment 5

[Kathleen Wilson]

See:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/
https://wiki.mozilla.org/CA:MaintenanceAndEnforcement#Potential_Problems.2C_Prevention.2C_Response

If further policy updates are needed, please add an issue here:
https://github.com/mozilla/pkipolicy/issues/