Opened 20 months ago

Closed 14 months ago

Last modified 14 months ago

#16835 closed defect (fixed)

Root certificate requests

Reported by: dx Owned by:
Milestone: 2.11.0 Component: libpurple
Version: 2.10.11 Keywords:
Cc: Kromey, MrTux

Description

Putting all the root certificate requests in a single ticket. This matters for windows, which doesn't use the system cert store. One valid resolution is to start using the system cert store.

These are just the ones requested by users.

I have not checked their inclusion status in mozilla/google/microsoft/apple root stores.

Yes, this sucks.

Change History (19)

comment:1 Changed 20 months ago by dx

Ticket #11278 has been marked as a duplicate of this ticket.

comment:2 Changed 20 months ago by dx

Ticket #16478 has been marked as a duplicate of this ticket.

comment:3 Changed 20 months ago by dx

Ticket #16544 has been marked as a duplicate of this ticket.

comment:4 Changed 20 months ago by dx

Ticket #16806 has been marked as a duplicate of this ticket.

comment:5 Changed 20 months ago by dx

Ticket #16805 has been marked as a duplicate of this ticket.

comment:6 Changed 20 months ago by dx

Ticket #16199 has been marked as a duplicate of this ticket.

comment:7 Changed 20 months ago by dx

Ticket #16189 has been marked as a duplicate of this ticket.

comment:8 Changed 17 months ago by piotrjurkiewicz

Few days ago jabber.org free XMPP service switched to a new certificate, which cannot be verified by current Windows version of Pidgin.

The new certificate is signed by "Let's Encrypt Authority X1" certificate, which in turn is signed by "DST Root CA X3".

Windows Pidgin installation does not contain "DST Root CA X3", so cannot verify the new jabber.org certificate.

Lack of this particular root CA was already reported in #16805 and is aggregated in the list in this bug report.

However, I think that adding more and more new root certificates to Pidgin Windows distribution is not a solution here -- such requests will repeat over and over. Pidgin on Windows should start using system certificate store, similarly as it does on other operating systems. Windows system root certificates are updated by Windows Update mechanism, what can ensure quick removal of compromised root certs and addition of new certs. Moreover, most entities have security policies which require regular WU updates, but they not have similar policies requiring regular utility apps updates. Finally, now Windows user must trust Pidgin Windows bundle packager and provider (Sourceforge). It would be better if he would have to trust just Microsoft (as he must trust it already).

In case of this particular certificate, switching to system cert store would solve the problem -- "DST Root CA X3" is a trusted Windows root.

comment:9 Changed 17 months ago by AnonymerGrizzley

I totally agree with you. But it seems this issue isn't going to be fixed soon. I stumbled upon this bug report as I wanted to use a Let's encrypt certificate on my XMPP server. CA adoption latency seems to be rather slow for Pidgin (I saw some taking 1 year from report to integration), so using the certificate store would for sure improve that. It seems to be done like this on the Linux version anyway, at least my LE certificate works for Pidgin on Ubuntu? If there are reasons for not using the Winwdows certificate store I'm not aware of, it would at least be helpfull to be able to add a CA on your own. There's no fun in readding a LE certificate every 90 days (because the validity period is only 90 days)

So here's a +1 from my side

comment:10 follow-up: Changed 15 months ago by MrTux

GPLv2+ licensed code for using the Windows trust store for verifying certificates can be found here: https://gitlab.com/tortoisegit/tortoisegit/commit/8d8760c9b2aa06784ce0c13aa56cea92e05c1240 (the accept unknown certificate code isn't needed as the current fallback an be used, just use src/Utils/CertificateValidationHelper.h, also see CAppUtils::Git2CertificateCheck where it is called on hiow to convert a DER-certificate to a Windows certificate object)

Last edited 15 months ago by MrTux (previous) (diff)

comment:11 in reply to: ↑ 10 Changed 15 months ago by EionRobb

Replying to MrTux:

GPLv2+ licensed code for using the Windows trust store for verifying certificates can be found here:

I had a go of this and my result is at https://bitbucket.org/EionRobb/pidgin/commits/9153cb4f5250787a15d955c8442bf04ac3f9de06

Unfortunately the way that libpurple is set up, it's not possible to use the Windows store with the NSS SSL plugin, as NSS wants all the certs in a directory - you can't mix-and-match certificates with SSL engines

comment:12 follow-ups: Changed 15 months ago by MrTux

Unfortunately the way that libpurple is set up, it's not possible to use the Windows store with the NSS SSL plugin, as NSS wants all the certs in a directory

I don't understand. NSS SSL tries to verify a cert, fails and then you can give the certificate to the Windows trust store (w/o the need to do all encryption using cryptoapi) to verify if it suceeds just say accept it to NSS.

comment:13 in reply to: ↑ 12 Changed 15 months ago by MrTux

Replying to MrTux:

Unfortunately the way that libpurple is set up, it's not possible to use the Windows store with the NSS SSL plugin, as NSS wants all the certs in a directory

I don't understand. NSS SSL tries to verify a cert, fails and then you can give the certificate to the Windows trust store (w/o the need to do all encryption using cryptoapi) to verify if it suceeds just say accept it to NSS or do the old code path with the user dialog otherwise.

comment:14 in reply to: ↑ 12 ; follow-up: Changed 15 months ago by EionRobb

Replying to MrTux:

Unfortunately the way that libpurple is set up, it's not possible to use the Windows store with the NSS SSL plugin, as NSS wants all the certs in a directory

I don't understand. NSS SSL tries to verify a cert, fails and then you can give the certificate to the Windows trust store (w/o the need to do all encryption using cryptoapi) to verify if it suceeds just say accept it to NSS.

Try and implement it and see.

NSS can only use the NSS cert store. Win32 can only use the win32 cert store. gnutls can only use the gnutls cert store. There's no mix-and-match.

comment:15 in reply to: ↑ 14 Changed 15 months ago by MrTux

Replying to EionRobb:

Try and implement it and see.

NSS can only use the NSS cert store. Win32 can only use the win32 cert store. gnutls can only use the gnutls cert store. There's no mix-and-match.

This is true, but only in a very strict sense. NSS and OpenSSL and other libraries do check the certificates with their own cert store. But if that fails, all crypto APIs I know have a callback which is called when validation failed and then there a pointer to the certificate (DER-encoded) is included. Now, within THIS callback (which is coded outside of NSS) where the dialog for the user is shown right now, you can also use the certificate validation of the Windows CryptoAPI to verify that DER-encoded certificate (there is a special API for this, no need to do the whole encryption with CryptoAPI). I used that API in the code I linked here.

At the end I don't care if NSS or CryptoAPI is used for the whole encryption. However, I do care for certificate validation.

PS: TortoiseSVN uses OpenSSL for encryption, but also uses the Windows cert store as TortoiseSVN comes with an empty OpenSSL cert store, so the certificate check failed callback is called for all certificates.

Last edited 15 months ago by MrTux (previous) (diff)

comment:16 Changed 14 months ago by dx <dx@…>

  • Milestone set to 2.10.13
  • Resolution set to fixed
  • Status changed from new to closed

(In [d37d62d692e4]):
ca-certs: Add mozilla cert bundle and remove old/redundant certs

Fixes #16835

The bundle comes from https://curl.haxx.se/ca/cacert-2016-04-20.pem

It can be validated by regenerating it with mk-ca-bundle as mentioned in https://curl.haxx.se/docs/caextract.html

Deleted, not in the bundle:

  • Verisign_Class3_Primary_CA.pem
  • VeriSign_Class_3_Primary_CA-G2.pem
    • obsolete roots of verisign, the former has a md2 signature
  • VeriSign_International_Server_Class_3_CA.pem
    • reissued version of intermediate for the md2 signed root above
    • added in 2853720ef300 (2009) for AOL
  • America_Online_Root_Certification_Authority_1.pem
  • AOL_Member_CA.pem
  • Microsoft_Internet_Authority_2010.pem
  • Microsoft_Secure_Server_Authority_2010.pem
  • Thawte_Premium_Server_CA.pem

Deleted, already in the bundle:

  • VeriSign_Class_3_Primary_CA-G5.pem
  • VeriSign_Class_3_Primary_CA-G5-2.pem
  • AddTrust_External_Root.pem
  • Baltimore_CyberTrust_Root.pem
  • Certum_Root_CA.pem
  • Certum_Trusted_Network_CA.pem
  • Deutsche_Telekom_Root_CA_2.pem
  • DigiCertHighAssuranceEVRootCA.pem
  • Go_Daddy_Class_2_CA.pem
  • StartCom_Certification_Authority.pem
  • Thawte_Primary_Root_CA.pem

Deleted intermediates with issuer in the bundle:

  • VeriSign_Class3_Extended_Validation_CA.pem
  • DigiCertHighAssuranceCA-3.pem

Kept, but not in the bundle:

comment:17 Changed 14 months ago by dx

Note: there were some changes in the commits that followed, 4c11c13d2748 bb3eba9e4bb6 e95572194d41

In the "Kept, but not in the bundle" section, all the certs except the two cacert ones are gone, because we've determined they are not needed. See the commit messages for details.

comment:18 Changed 14 months ago by Robby

  • Milestone changed from 2.10.13 to 2.11.0

comment:19 Changed 14 months ago by dx

Ticket #14475 has been marked as a duplicate of this ticket.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!