Re: Audit Archiving in CCADB
Thanks to all of you who provided suggestions about how to resolve the sun.security.validator.ValidatorException errors. JC has provided a .jks file of the NSS keystore as of December 19, 2016. So, we will try resolving the errors by using this .jks file. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audit Archiving in CCADB
Den 15-12-2016 kl. 00:12 skrev Kathleen Wilson: 1) Salesforce (in cloud) is using the default Java root store, which is smaller than Mozilla's root store. This accounts for the "sun.security.validator.ValidatorException: PKIX path building failed:" errors. We're not yet sure how to tell the Java program in the Salesforce cloud to use a different root store, so please point me in the right direction if any of you have dealt with this before. How have you implemented the fetching? Are you using the Salesforce platform? You can only make callouts to a set of Remote Sites that you have whitelisted. That does not seem fit to your use case. There are ways to hack around this. You can for example add your Salesforce domain to the whitelist, which allows code running within Salesforce to dynamically deploy changes to the whitelist. Is that what you are doing? If that is the case, you cannot change which certificates it trusts, because you cannot reach down into the Java layer. A solution would be to use some kind of proxy outside the Salesforce platform, which can have its own certificate validation logic. A bonus with doing it that way is that you can then avoid having self-modifying code running in your system, and the related potential for security issues. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audit Archiving in CCADB
Thanks once again for this work Kathleen, On Wednesday, 14 December 2016 23:12:51 UTC, Kathleen Wilson wrote: > 1) Salesforce (in cloud) is using the default Java root store, which is > smaller than Mozilla's root store. This accounts for the > "sun.security.validator.ValidatorException: PKIX path building failed:" > errors. > We're not yet sure how to tell the Java program in the Salesforce cloud to > use a different root store, so please point me in the right direction I believe the Java system property javax.net.ssl.trustStore (please verify spelling before using) points to a Java Keystore format list of trusted CA certificates which will be used for default SSL connections. I am responsible for some code that manipulates this programatically for our non-public HTTPS-based APIs but the hint above should be enough for a Mozilla person or Salesforce expert to get it working without the bureaucracy of releasing that code. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audit Archiving in CCADB
On Wednesday, December 14, 2016 at 3:23:39 PM UTC-8, Kathleen Wilson wrote: > On Wednesday, December 14, 2016 at 3:12:51 PM UTC-8, Kathleen Wilson wrote: > > All, > > > > We have added Audit Archiving to the Common CA Database (a.k.a. CA > > Community in Salesforce). > > > For completeness... > > Here's a pageshot showing the audit statements that were successfully > archived: > > https://pageshot.net/NXLnNjLVbyBameqQ/na17.salesforce.com > > Kathleen Updated to correct title of the report... https://pageshot.net/a9oRnZ2gioyNO1gN/na17.salesforce.com ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Audit Archiving in CCADB
All, We have added Audit Archiving to the Common CA Database (a.k.a. CA Community in Salesforce). https://wiki.mozilla.org/CA:SalesforceCommunity#Audit_Archive ~~ As of December 13, 2016, audit statements for root certificates in the Common CA Database are archived. The CCADB will regularly run a program to determine which audit statement links have been updated, and download the pdf file as a permanent record. ~~ See wiki page for details ~~ Currently audit archiving is only for root certificate records. (I do plan on adding this to intermediate cert records in the future -- it's on my to-do list...) Here is a pageshot of the failed attempts to archive audit statements: https://pageshot.net/2yamFdLdegHH3CEu/na17.salesforce.com There are two problems that need to be solved: 1) Salesforce (in cloud) is using the default Java root store, which is smaller than Mozilla's root store. This accounts for the "sun.security.validator.ValidatorException: PKIX path building failed:" errors. We're not yet sure how to tell the Java program in the Salesforce cloud to use a different root store, so please point me in the right direction if any of you have dealt with this before. 2) The webtrust.org site is still using TLSv1.0, and Salesforce now requires TLSv1.1 or higher. We have implemented a work-around that will fail in March. Hopefully the webtrust.org site will be upgraded before then. I think the rest of the errors are just data that needs to be fixed -- the audit archive program needs the URLs to point to pdf files. I should be able to resolve the data problems within the next week or so. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
