1017562 - Trustis: Certificate not version 3

Status: RESOLVED FIXED

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

Description

[Kurt Roeckx]

I'm seeing a version 1 certificate from the following chain:
OU = Trustis FPS Root CA, O = Trustis Limited, C = GB
CN = Trustis Healthcare TT Issuing Authority, OU = Trustis FPS, O = Trustis Limited, C = GB

Comment 1

[Kathleen Wilson]

Hi Rob, Would you please find out why a version 1 certificate got issued, replace it, and make sure it won't happen again? 

v1 TLS end-entity certificates do not comply with our policy because a v1 certificate cannot (according to the spec) contain a subjectAltName extension and we require all TLS end-entity certificates to contain
subjectAltName. 

Please post your updates and conclusions in this bug.

Comment 2

[Rob Horne]

Hi Kathleen, We believe the certificate identified is a certificate used for specific functions associated with protection in relation to components of the Certification Authority operations. Certificates of this nature are only for use internally to the Certification Authority and so no risk arises in terms of lifecycle and private key use. 

In order to confirm this is correct we will need the serial number and DN of the certificate in question.

Comment 3

[Kurt Roeckx]

Attachment: notv3.pem

Comment 4

[Rob Horne]

The software used by this CA automatically generates a number of certificates for internal communication between different parts of the application; we know these are V1 certificates and occasionally expose them externally for validation and testing purposes. These are always under the direct control of Trustis and not issued to customers; with the benefit of the additional information you provided we have established the one reported to us is not one of these.   

The certificate in question is an end-entity certificate issued to a customer. The RA issuing process is technically constrained to ensure the profile against which the certificate is issued is compliant. In this instance a technical problem had arisen from browser updates issued by Microsoft, whereby the RA web portal, although displaying the correct profile, has submitted the CSR incorrectly to the CA. 

The V1 certificate has been revoked and a replacement will be issued. The Subscriber has been contacted to ensure the corresponding private key will be replaced.

We are conducting a root cause analysis to determine the full and exact nature of the problem.  In the meantime we have implemented an additional manual check of every end-entity certificate for compliance. 

We are also conducting a full review of all issued certificates to ensure compliance in every case.

Thank you to Kurt and to yourself for bringing this so quickly to our attention.

Comment 5

[Kurt Roeckx]

Thanks for the update Rob.

I would like to keep this open until you believe the root cause has been found and addressed.  Can you update us when things changed?

Comment 6

[Rob Horne]

Hi Kurt, not a problem and I'm now able to report back our findings:

For the certificate in question, access to the RA portal is conducted over https using two-factor authentication via a web browser on a dedicated PC. During May the dedicated PC was upgraded, this included the automatic installation of Microsoft Internet Explorer 11. When the RA Operator accesses the RA portal, the only certificate profile presented for the RA operator to use enforces version 3. It is coded into the access interface the RA operator uses and is not adjustable. Upon certificate issuance there was no indication at the RA of anything amiss and the RA Operator had followed the procedure as required. The root cause of the problem was interaction between IE11 and the RA interface resulting in it failing to correctly pass on a properly formatted request to the RA and RA subsequently passed the malformed request to the CA. 

Further internal testing has reproduced and confirmed the fault which was hereto unknown. It has been confirmed the problem is manifested only on IE11 and no other RA operator interactions are affected. . 
Our investigation showed three version 1 certificates had been issued, the one noted above, and two others which were not exposed to the public Internet.  As reported earlier, customers were contacted and all three certificates were revoked. The customers involved have forwarded CSRs using new private keys which have since resulted in new certificates being issued.

Our  actions which have been completed were. 

- To procedurally prevent the use of IE11 for issuance of certificates on this RA technology platform.
- To remove IE11 from the devices used to access RA technology platform. 
- To instigate a specific enhancement in the compatibility checking procedure for those PCs used for interaction with the RA portal.  

The incident was controlled under our ISMS.

Comment 7

[Kurt Roeckx]

I found 3 more version 1 certificates live on the internet that aren't revoked that didn't show up previously. They're all in the *.trustis.com domain.

Comment 8

[Rob Horne]

Dear Kurt,

Thanks for your post. Yes you are correct. That's what I would expect, see my post to this bug, 2014-06-02 03:59:47 PDT.

Comment 9

[Kurt Roeckx]

Hi Rob,

Even if they are for "internal use" only, I think it would be best that they would stop being used and be replaced by v3 certificates.

Comment 10

[Gervase Markham [:gerv]]

Kurt: do the certificates in question assert id-kpServerAuth in their EKU?

Gerv

Comment 11

[Kurt Roeckx]

(In reply to Gervase Markham [:gerv] from comment #10)
> Kurt: do the certificates in question assert id-kpServerAuth in their EKU?

They are v1 certificates, they don't have extentions, and so can't assert that.