1174118 - Name Constrained SMIMECertificates with additional EKU Constraints not working for "unknown reason"

Status: RESOLVED WORKSFORME

(Thunderbird :: Security, defect)

Description

[Steve Roylance]

Attachment: Name Constraints issue with Thunderbird.pdf

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 Safari/537.36

Steps to reproduce:

Please see Name Constrained SSL Certificates with additional EKU Constraints incorrectly reported as "Not Trusted" in FF https://bugzilla.mozilla.org/show_bug.cgi?id=1174087 for similar issues (but not exactly the same).


Actual results:

Open the certificate revived in a signed SMIME e-mail.  It cannot be verified.


Expected results:

The end entity certificate (As well as the issuing CA) is deemed not to be trusted.
The correct chaining should happen and the appropriate EKU nesting should also be supported.
Version 31.7

Comment 1

[Steve Roylance]

Attachment: Thunderbird exported certificate chains.zip

The attached is a zip renamed to txt which has the various p7c files from my testing.  These are based on 'real' chains in production.

It has not been possible to simulate the errors as any test certificates installed will fail to show the same error as the installation demands prperties of the CA are added (SSL SMIME etc) and it cannot be set a a built in token.

Comment 2

[Steve Roylance]

Thanks and good luck trying to identify.

FYI here's a tool to be able to create Name and EKU constrained CA's.  The test roots are downloadable from the page as is the test subordinate issuing CA (No OCSP as it's only a long term CRL).  Simply create a name and EKU constrained CA by added those names and EKUs via the menu and use any CSR to create the CA.

109.228.18.69/trusted/ 

Let me know any issues.

Comment 3

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Hi Steve,

Please confirm that you're still seeing this issue with a new profile on the latest version of Thunderbird (should be 38.0.1). Also, the attached certificate chains appear to all consist of intermediates and roots. It would be easier to debug this problem with an end-entity certificate that's failing.

Thanks.

Comment 4

[Steve Roylance]

I've checked and this now seems to be corrected.  I shall revert back to the original customer who reported and see if they too see that the issue has been resolved.   Is there an explanation of the issue as I also saw similar issues with Firefox recognition of chains.

I saw that the certificate view does not (on my system) show the embedded Root CA in the chain view of an end entity, but the end entity certificate is indeed correctly reported.

Thanks.

Comment 5

[Wayne Mery (:wsmwk)]

WFM based on "this now seems to be corrected"