Bug 30902 - Cert store uses non-unique primary key
Summary: Cert store uses non-unique primary key
Status: ASSIGNED
Alias: None
Product: Class Libraries
Classification: Mono
Component: Mono.Security ()
Version: master
Hardware: PC Linux
: --- normal
Target Milestone: Untriaged
Assignee: Martin Baulig
URL:
: 28602 ()
Depends on:
Blocks:
 
Reported: 2015-06-08 09:47 UTC by Jo Shields
Modified: 2017-02-15 17:03 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Cert 1 (2.70 KB, application/x-x509-ca-cert)
2015-06-08 09:49 UTC, Jo Shields
Details
Cert 2 (2.61 KB, application/x-x509-ca-cert)
2015-06-08 09:49 UTC, Jo Shields
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report for Bug 30902 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
ASSIGNED

Description Jo Shields 2015-06-08 09:47:17 UTC
Every package update. I get a message from cert-sync:

I already trust 172, your new list has 173
Certificate added: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Certification Authority
1 new root certificates were added to your trust store.

This message is actually quite legit.

StartCom reissued a root CA cert. Same CN, same validity, different serial number and fingerprint.

The filename we use in our certificate store is of the form ski-${X509v3 Subject Key Identifier}.cer, where the X509v3 Subject Key Identifier extension exists. However, in this situation, the X509v3 Subject Key Identifier is the same on both (still valid, still in circulation) certificates. When we add one to the cert store, then add the other, the operation silently fails (as the same filename is used for both certs).

This can be seen in Mono.Security.X509/X509Store.cs where GetUniqueName (string method, byte[] name, string fileExtension) uses only the method ("ski" or "tbp"), a string representation of the "name" (i.e. the SKI, in certs with a SKI), and a file extension.

I feel the easiest workaround to this problem would be to add the certificate serial number to the filename, i.e. have ski-4E0BEF1AA4405BA517698730CA346843D041AEF2-1.cer and ski-4E0BEF1AA4405BA517698730CA346843D041AEF2-45.cer as distinct filenames.
Comment 1 Jo Shields 2015-06-08 09:49:07 UTC
Oh, related note - if we fix the filename to allow both certs to be imported, we don't currently have a way to *delete* them separately. "certmgr -d" doesn't have any way to disambiguate
Comment 2 Jo Shields 2015-06-08 09:49:43 UTC
Created attachment 11507 [details]
Cert 1
Comment 3 Jo Shields 2015-06-08 09:49:59 UTC
Created attachment 11508 [details]
Cert 2
Comment 4 Alexander Köplinger [MSFT] 2016-02-12 13:48:43 UTC
*** Bug 28602 has been marked as a duplicate of this bug. ***
Comment 5 Sebastien Pouliot 2016-02-12 14:05:59 UTC
Modifying `GetUniqueName` sounds good*, but you'll have to check (grep / test) to see if it's being used elsewhere.

* I think the name might be used to help creating certificate chain (at least I'm pretty sure there was a reason for not using the hash for the filename). If so you'll need to update that code too.


WRT comment #1 it should not be an issue as the deletion is done from the certificate's hash (which is different since the certificate are, even if not much, different).
Comment 6 Jo Shields 2016-02-12 16:09:00 UTC
https://github.com/mono/mono/pull/2609
Comment 7 Jo Shields 2017-02-15 14:46:24 UTC
I'm reopening this bug, as it now affects BTLS.

Importing into BTLS system store:
I already trust 172, your new list has 174
Certificate added: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Certification Authority
Certificate added: C=US, O="VeriSign, Inc.", OU=Class 3 Public Primary Certification Authority
2 new root certificates were added to your trust store.
Import process completed.

With OpenSSL, normally, certs with matching hashes but mismatched serials get a changed suffix - i.e.:

C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Certification Authority exists on Debian/Ubuntu as both ae8153b9.0 and ae8153b9.1 - it seems our BTLS is only handling the basic .0 case.
Comment 8 Martin Baulig 2017-02-15 17:03:11 UTC
This is little to nothing that we can do about this with BTLS - except maybe providing some kind of a work-around such as for instance manually removing / blacklisting one of those CA certificates.

Having two certificates with the same X.500 name in the same certificate directory is not a supported scenario - and we can't change this without making some larger modifications to their certificate store lookup code.

This is the relevant native code:
https://github.com/mono/boringssl/blob/mono/crypto/x509/by_dir.c#L256

I just had a quick look at openssl and their version of that file isn't too different - they're also doing the lookup based on name-only.