599856 - A certificate issued to a company that doesn't exist

Status: RESOLVED FIXED

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

Description

[Paul van Brouwershaven]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.17 Safari/534.7
Build Identifier: 

oday I came across an 'organizational validated' certificate issued on September 20 2010 by a partner of Comodo.

The subject of the certificate (see attachment for full certificate details):

Subject: C=NL/postalCode=2061CH, ST=Noord-Holland, L=Bloemendaal/streetAddress=Bloemendaalseweg 139, O=TEMPEL, OU=internet, OU=Hosted by Cysonet Managed Hosting, OU=Comodo InstantSSL, CN=www.tipharma.com

The Dutch trade register (Chamber of Commerce) gives no results for a company named "TEMPEL" in Bloemendaal, there is only one company named "Computer Service Bureau Tempel" in Losser that uses the trading name "Tempel" and the owner of this company confirmed me that this is not the same company nor they have any relations with a company in Bloemendaal.

After some minor research I found the company "TEMPEL Interactive B.V.", formerly actively on the Bloemendaalseweg 139, Bloemendaal but since 1 July 2007 they are located at the Nieuwe Gracht 74-76, Haarlem and they don't have a registered trading name "TEMPEL".

The certificate revocation list as listed in the certificate (Serial: 3008, Last Update: Sep 27 00:41:12 2010 GMT) does not contain a certificate with serial 7E27F096AC400FE97C79AFA3096DE316.

This certificate shows that Comodo resellers are:
1) Still able to validate certificates when Comodo says they no longer allow to do this
2) Shows that Comodo Resellers are still not making the appropriate OV checks
3) After a number of misissued certificates Comodo continue to allow this

What will be the action now? Will Mozilla take any action or not do anything about it?
 
Mozilla states here: https://wiki.mozilla.org/CA:Problematic_Practices#Validate_all_Data_included_in_Certificates 
 
"Only data that has been verified to be correct should be included in a certificate. All information that is supplied by the requester must be verified to be correct before it may be included in the certificate. For example, for SSL certificates, alternative names need to be validated just as well as the subject."
 
How can Mozilla and/or any of us prevent Comodo from allowing their resellers to issue non-validated certificates?
 
This has happened too many times now and in the end will make SSL worthless as a viable authentication and encryption product.

Reproducible: Always

Comment 1

[Paul van Brouwershaven]

Attachment: Certificate for www.tipharma.com

Comment 2

[Paul van Brouwershaven]

Attachment: Whois information for tipharma.com

Comment 3

[Johnathan Nightingale [:johnath]]

Seems the sporting thing to do would be to bring in some Comodo folk, eh what?

Comment 4

[Robin Alden]

Hi,
   We agree that the address details on that certificate are no longer correct and we will be asking the subscriber to put an updated certificate on their site.
We will not revoke this certificate until the subscriber has had the opportunity to put the amended certificate live (unless they were to take an inordinately long time to do so).

We have issued certificates to this organization (at this Organization name and address) since late 2006, at which time the address was valid.
We accepted the "TEMPEL" Organization name because they demonstrated to us that they were operating under that name and we had (and have) no reason to think the name misleading.

Even the EV guidelines allow for not rechecking the physical address on a renewal if the applicant states that it is still the correct address.

The subscriber should, of course, have informed us of their change of address, but we will not punish them for their oversight by revoking without notice.

I agree that a reissuance is necessary (because of the out-of-date address), but I disagree that the existence of this certificate demonstrates that our policies or practices are inadequate to prevent misuse.

Regards
Robin Alden
Comodo

Comment 5

[Paul van Brouwershaven]

Robin, you say that they demonstrated to use of the company name "TEMPLE".

1) If for example a criminal is using the name X it will not say that they are allowed to use this name. This sounds as really basic fault because you can't relay the requester. (this could be the criminal)

2) A company that for example registered the trade name "TEMPEL Interactive B.V." cannot simply shorten it and use "TEMPEL" because you feel like it.

3) Why should you applicant state they still are active on this address from years ago? Not informing is not the same as making a statement!

Comment 6

[Paul van Brouwershaven]

Hi Robin,

More then a month later we are still waiting on your update.

One day afther your post on this bug the site owner has installed a new certificate on their server, till now the old certificated has not been revoked (serial 3091, updated: Nov  7 17:19:58 2010 GMT) and there has been no update from your side to this issue.

In my initial post I stated that this certificate shows that Comodo resellers are:

1) Still able to validate certificates when Comodo says they no longer allow to
do this
2) Shows that Comodo Resellers are still not making the appropriate OV checks
3) After a number of misissued certificates Comodo continue to allow this

Also the replacing certificate confirms that the initial certificate was not properly validated as this new certificate if issued to an other company on different address.

CN = www.tipharma.com
OU = Comodo InstantSSL
OU = Hosted by Cysonet Managed Hosting
OU = internet
O = Stichting Top Institute Pharma
STREET = Galileiweg 8
L = Leiden
S = Noord-Holland
PostalCode = 2333AL
C = NL

a) How will Comodo ensure that this will not happen again?

b) What does this issue say about the current certificate base?

Comment 7

[Robin Alden]

(In reply to comment #6)
> ...
> One day afther your post on this bug the site owner has installed a new
> certificate on their server, till now the old certificated has not been revoked
> (serial 3091, updated: Nov  7 17:19:58 2010 GMT) and there has been no update
> from your side to this issue.

The old certificate has now been revoked.

> 
> In my initial post I stated that this certificate shows that Comodo resellers
> are:
> 
> 1) Still able to validate certificates when Comodo says they no longer allow to
> do this

You misquote us.  I have said that we still have external RAs, but that not all resellers are RAs.

> 2) Shows that Comodo Resellers are still not making the appropriate OV checks

We have Resellers and we have RAs.  RAs do (should) make appropriate OV checks.  

The RA had validated the initial purchase of a certificate for this customer on this domain originally in accordance with our guidelines at the time.  
However, they did not re-validate the information at the time of certificate renewal.  Our validation guidelines do allow the limited re-use of validation information, but in this case the certificate should have been revalidated when it was renewed and the subject should have been updated at that point.

The WHOIS registrant details were, until recently, the same details as you saw in the original certificate.

> 3) After a number of misissued certificates Comodo continue to allow this
> 
> Also the replacing certificate confirms that the initial certificate was not
> properly validated as this new certificate if issued to an other company on
> different address.
> 

We agreed in our initial response to this bug that the subject details in the certificate were no longer correct.

The new certificate has been issued with a subject which is currently correct.
The subscriber remains the same.
The domain protected by the certificate remains the same.

> a) How will Comodo ensure that this will not happen again?

That is a fair question.  
* We will undertake to clarify and re-distribute our guidance to RAs (external and internal) with respect to the re-use of validation documentation previously gathered.
* We have already removed this RA's ability to act as an RA and we will not re-instate it until they have successfully demonstrated over a period of time that they understand and are applying the guidance correctly.
* We will complete the review of the other validation undertaken by this RA.

> 
> b) What does this issue say about the current certificate base?

It says to me that no control is 100% effective.  There is always scope for error.
We have processes in place to review both the domain validation and organizational validation work of RAs (external and internal) and despite having those controls in place errors such as this will occur from time to time.
Our policies and procedures are implemented (and audited) to provide "reasonable assurance" of accuracy of certification as required by WebTrust.

We issue a very large number of certificates with very few errors.
We disagree that there are "many cases" of error.  Other CAs, even some who issue relatively few certificates, make mistakes too.
Our validation processes (including our RAs) correct many genuine errors in certificate applications by subscribers and block a considerable number of attempts to obtain certificates fraudulently.

This is not a case of fraud.
This is not a case of a failure of domain validation.
This is a case of outdated information remaining in a certificate across a renewal.  
I appreciate that there have been discussions concerning the consequence of a change of domain control (e.g. because of a domain transfer during the life of a certificate) but even that is not the case here - the same subscriber retains control of the domain.

I am pleased that this subscriber now has the correct organizational information in the subject of the certificate on his domain.
I would be even more pleased if Firefox would display the organizational information that is worthy of so much care and discussion.

Regards
Robin

Comment 8

[Paul van Brouwershaven]

Hi Robin,

Thanks that you finally found some time to come back to this issue to provide some feedback.

(In reply to comment #7)
> The old certificate has now been revoked.
Ok

> > 1) Still able to validate certificates when Comodo says they no longer allow to
> > do this
> 
> You misquote us.  I have said that we still have external RAs, but that not all
> resellers are RAs.
Can you give an idea of number of RAs you currently have? I know some so it should be pretty much!

> We have Resellers and we have RAs.  RAs do (should) make appropriate OV checks. 
> 
> The RA had validated the initial purchase of a certificate for this customer on
> this domain originally in accordance with our guidelines at the time.  
> However, they did not re-validate the information at the time of certificate
> renewal.  Our validation guidelines do allow the limited re-use of validation
> information, but in this case the certificate should have been revalidated when
> it was renewed and the subject should have been updated at that point.

As I understand right your RAs doesn't have to follow a training nor there understanding of the guidelines is regularly (minimal once a year!) tested/audited?
 
> The WHOIS registrant details were, until recently, the same details as you saw
> in the original certificate.

I was able to check the whois information back to the registration date at November 2006 and the domain was allocated to the non existing company TEMPEL since then.

The validation should not rely on the whois information only (we all know that this information can't be trusted because there is validation on it), it looks like your RA just copied the information from the whois database.

> > 3) After a number of misissued certificates Comodo continue to allow this
> > 
> > Also the replacing certificate confirms that the initial certificate was not
> > properly validated as this new certificate if issued to an other company on
> > different address.
> > 
> 
> We agreed in our initial response to this bug that the subject details in the
> certificate were no longer correct.
> 
> The new certificate has been issued with a subject which is currently correct.

> The subscriber remains the same.

Does the subscriber says anything about the organization? I could start working for an other company and be the same person but not working for the same organization.

"O=TEMPEL" != "O=Stichting Top Institute Pharma"

> The domain protected by the certificate remains the same.
:-)

> > a) How will Comodo ensure that this will not happen again?
> 
> That is a fair question.  
> * We will undertake to clarify and re-distribute our guidance to RAs (external
> and internal) with respect to the re-use of validation documentation previously
> gathered.
> * We have already removed this RA's ability to act as an RA and we will not
> re-instate it until they have successfully demonstrated over a period of time
> that they understand and are applying the guidance correctly.
> * We will complete the review of the other validation undertaken by this RA.

Are you willing to share the results?

> > b) What does this issue say about the current certificate base?
> 
> It says to me that no control is 100% effective.  There is always scope for
> error.

I agree with this, nobody is perfect and everyone makes mistakes.

> We have processes in place to review both the domain validation and
> organizational validation work of RAs (external and internal) and despite
> having those controls in place errors such as this will occur from time to
> time.

Are these controls sufficient? This is not the first certificate and probably not the last that was issued incorrectly because your RAs have not followed the rules.

> Our policies and procedures are implemented (and audited) to provide
> "reasonable assurance" of accuracy of certification as required by WebTrust.

But if your policies or procedures are not sufficient, it says nothing.

> We issue a very large number of certificates with very few errors.
> We disagree that there are "many cases" of error.  Other CAs, even some who
> issue relatively few certificates, make mistakes too.

Everyone makes mistakes, but as far I remember most issues with Comodo have been related to the RAs who haven't followed the validation procedures.

> Our validation processes (including our RAs) correct many genuine errors in
> certificate applications by subscribers and block a considerable number of
> attempts to obtain certificates fraudulently.
> 
> This is not a case of fraud.

You are lucky :-)

> This is not a case of a failure of domain validation.

Depending on how you see the validation, yes likely there was a automated domain validation based on mail and this confirms that there is control over the domain. I case of an OV certificate you would like to know if the organization is the owner of the domain name.

> This is a case of outdated information remaining in a certificate across a
> renewal.

It's not about outdated information, the information has never been correct!

> I appreciate that there have been discussions concerning the consequence of a
> change of domain control (e.g. because of a domain transfer during the life of
> a certificate) but even that is not the case here - the same subscriber retains
> control of the domain.

But it's not the subscriber who is listed in the certificate

> I am pleased that this subscriber now has the correct organizational
> information in the subject of the certificate on his domain.
> I would be even more pleased if Firefox would display the organizational
> information that is worthy of so much care and discussion.

I would be pleased if the browsers would display the organizational information too, but only if there is a proper validation standard for OV.

Regards,

Paul

Comment 9

[Kathleen Wilson]

Reference:
https://cabforum.org/baseline-requirements-documents/
https://wiki.mozilla.org/CA:BaselineRequirements
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

If further policy updates are needed for this, please file the issue here:
https://github.com/mozilla/pkipolicy/issues/

> I would be pleased if the browsers would display the organizational information too, 
> but only if there is a proper validation standard for OV.

Mozilla only shows organization info for EV certs. No plan to change that.