Closed
Bug 1501374
Opened 6 years ago
Closed 6 years ago
Comodo CA issuing EV Certs without Higher Authority checks
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: hon1nbo, Assigned: Robin.Alden)
Details
(Whiteboard: [ca-compliance])
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36 Steps to reproduce: Start process to issue a Comodo-CA EV certificate Actual results: Requestor (myself) received phone call to approve Certificate was issued. This is a serious violation of authentication and audit requirements for EV certificates to be issued, as Comodo isn't checking the higher authorities. Attack scenario: user with mail server access uses it for the initial domain validation and issues a request. By not verifying with a higher authority, certificate will be issued to someone without the authority to receive it. I don't have a direct line with anyone in the CAB forum, so this seemed like my best bet besides randomly tweeting / posting into the void. Expected results: Phone call should have been placed to a higher authority, which in the case of a sole proprietor would be to the lawyer representing that I am who I say I am. Comodo never asked for this information, never asked for a face to face, and in general never asked for higher authority information. Per the CAB forum requirements, EVs cannot have the requestor and approver be the same person, the approver has to be a 3rd party in the case of a individual operated business such as myself.
Confirmation that the certificate was issued: https://sslmate.com/foreign_certs/details/2341519
Comment 2•6 years ago
|
||
(In reply to hon1nbo from comment #0) > User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 > (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36 > > Steps to reproduce: > > Start process to issue a Comodo-CA EV certificate > > Actual results: > > Requestor (myself) received phone call to approve > Certificate was issued. This is a serious violation of authentication and > audit requirements for EV certificates to be issued, as Comodo isn't > checking the higher authorities. Will you please describe what you mean by "higher authorities"? Do you mean that you do not have authority within your company to approve and sign as would be verified by EVGL section 11.8? > Attack scenario: user with mail server access uses it for the initial domain > validation and issues a request. By not verifying with a higher authority, > certificate will be issued to someone without the authority to receive it. > > I don't have a direct line with anyone in the CAB forum, so this seemed like > my best bet besides randomly tweeting / posting into the void. > You could also Contact Comodo at their problem reporting email address: sslabuse@comodoca.com > > Expected results: > > Phone call should have been placed to a higher authority, which in the case > of a sole proprietor would be to the lawyer representing that I am who I say > I am. > Comodo never asked for this information, never asked for a face to face, and > in general never asked for higher authority information. > Per the CAB forum requirements, EVs cannot have the requestor and approver > be the same person, the approver has to be a 3rd party in the case of a > individual operated business such as myself. I do not think this is a correct statement. I have assigned this bug to a Comodo representative so that they can determine if and how EV validation was properly conducted. > Confirmation that the certificate was issued: https://sslmate.com/foreign_certs/details/2341519 That URL is behind a login page. Can you provide one of the domain names contained in the certificate?
Assignee: wthayer → Rob.Stradling
Whiteboard: [ca-compliance]
>> Will you please describe what you mean by "higher authorities"? Do you mean that you do not have authority within your company to approve and sign as would be verified by EVGL section 11.8? Section 11.8.1(3) "EV Authority of Certificate Approver: The CA MUST verify, through a source **other than the Certificate Approver him- or herself**, that the Certificate Approver is expressly authorized by the Applicant to do the following, as of the date of the EV Certificate Request" It's not that I don't have authority, it's that the approver and the requestor are not allowed to be the same person per the CA|B. In handling individual owned LLCs, CAs generally seek a 3rd party to act as the approver to verify the requestor. Usually this is an attorney, a notary public, or similar institution (for all the previous EVs I've used my attorney personally, though other options apparently work as well). I actually fought having to do that previously as a nuisance, but each CA iterated the same statement, additionally pointing to that or similar CA|B clauses, that the approvers and requestors have to be different individuals. I am used to saying "higher authority" since that's what the last round I went through called it when it came to the approver versus requestor. Otherwise, a situation such as a rogue admin could occur in which the mail server administrator could issue EV certificates without approval of the business. In this case the email went out, and I received a phone call at a number that's not on file with the texas secretary of state (my personal rather than the business NOC phone). I didn't even answer at the time; I called in later and said I was Jim Hartnett. There wasn't actually a way for them to know I was who I said I was when I called in. They didn't ask for anything that someone such as a mail administrator wouldn't have access to should it be a rogue issue, I just gave them the order ID. I didn't even call from the same number they called me at. >> deaddrop.hackingand.coffee >> You could also Contact Comodo at their problem reporting email address: sslabuse@comodoca.com Don't know how I missed this one, thanks for the point. >> I do not think this is a correct statement. I have assigned this bug to a Comodo representative so that they can determine if and how EV validation was properly conducted. Thanks, we'll see how they answer. So far even from what I can tell it didn't even follow their own guidelines.
Comment 4•6 years ago
|
||
Rich or Robin, please could one of you comment on this?
Flags: needinfo?(rich)
Flags: needinfo?(Robin.Alden)
Updated•6 years ago
|
Assignee: Rob.Stradling → Robin.Alden
Assignee | ||
Comment 5•6 years ago
|
||
(In reply to hon1nbo from comment #3) > Section 11.8.1(3) "EV Authority of Certificate Approver: The CA MUST verify, > through a source **other than the Certificate Approver > him- or herself**, that the Certificate Approver is expressly authorized by > the Applicant to do the following, as of the date > of the EV Certificate Request" 11.8.3 (6) states the following: QIIS or QGIS: The Signing Authority of the Contract Signer, and/or the EV Authority of the Certificate Approver, MAY be verified by a QIIS or QGIS that identifies the Contract Signer and/or the Certificate Approver as a corporate officer, sole proprietor, or other senior official of the Applicant. For this certificate order, the certificate applicant is listed in a QGIS (Texas Secretary of State) as a corporate officer. That gives the applicant Signing Authority and EV authority. > In this case the email went out, and I received a phone call at a number > that's not on file with the texas secretary of state (my personal rather > than the business NOC phone). I didn't even answer at the time; I called in > later and said I was Jim Hartnett. There wasn't actually a way for them to > know I was who I said I was when I called in. They didn't ask for anything > that someone such as a mail administrator wouldn't have access to should it > be a rogue issue, I just gave them the order ID. I didn't even call from the > same number they called me at. We found the applicant's chosen phone number in a QIIS. This complies with EV 11.5.2 (A). To comply with EV 11.5.2 (B), a message was left at that phone number containing a unique confirmation code. The applicant called back and provided that unique confirmation code. There was some confusion as the caller added an extra digit on the first two readings, but then gave the code correctly on the third reading. The agent handling the call took the order number too as a double check that the right order was being processed.
Flags: needinfo?(Robin.Alden)
Updated•6 years ago
|
Flags: needinfo?(rich)
> The applicant called back and provided that unique confirmation code. > There was some confusion as the caller added an extra digit on the first two readings, but then gave the code correctly on the > > third reading. > The agent handling the call took the order number too as a double check that the right order was being processed. > There was some confusion as the caller added an extra digit on the first two readings, but then gave the code correctly on the > third reading. Ok, this is not what I was informed. I was told that the code I was providing was incorrect in each case, and I was given the option of pulling up the order via the order number send to the postmaster email. > We found the applicant's chosen phone number in a QIIS. I'll have to look into how that number ended up in whatever record was pulled up (guessing SOS), as that number isn't supposed to be there. There isn't control over who answers it, nor voicemails left. Apologies for the trouble, it seems there was confusion on the line when I was speaking with the verification representative. I'll also forward along the 11.5.2 section to the auditor to keep handy on file so this doesn't come up again. -Jim
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
Updated•4 years ago
|
Group: crypto-core-security
Updated•1 year ago
|
Product: NSS → CA Program
You need to log in
before you can comment on or make changes to this bug.
Description
•