Detect when certs can be changed, and link to replacement

[konklone]

We're now bringing down full intermediate data, with the merging of #30. Once #19 is merged, one ambitious goal could be to formalize some of the recommendations that @jonnybarnes and others found for intermediate SHA-2 certs into fingerprint mappings.

So, if we see a known replace-able intermediate cert, we can suggest its replacement in the UX. This also will require updating our cert parsing to keep the cert fingerprint during node-x509 parsing.

We need a data object that maps regexes of domains and intermediate names to names/links, something like:

{
  "cloudflare.com": {
    name: "Cloudflare",
    link: "https://twitter.com/cloudflare"
  },
  "github.io": {
    name: "GitHub",
    link: "mailto:[email protected]?subject=Update+github.io+to+use+SHA-2"
  },
  "DigiCert": {
    name: "DigiCert",
    link: "https://www.digicert.com/digicert-root-certificates.htm#intermediates"
  }
}

[jonnybarnes]

This presumably means we'd need to create some sort of db of SHA-1 intermediate CA certs and their equivalent SHA-2 certs.

[konklone]

Yeah, probably just a JSON object, it can be pretty lightweight and held in
memory on server load.

[jonnybarnes]

So would we want something like this?

{
    "startssl-class1-sha1": {
        "fingerprints": {
            "sha-1": "F6:91:FC:87:EF:B3:13:53:54:22:5A:10:E1:27:E9:11:D1:C7:F8:CF",
            "sha-2": "CB:2D:B5:73:61:0F:40:1E:8D:60:29:17:BB:BE:6A:B4:16:22:55:F2:08:EF:AD:90:9D:54:40:69:1A:A0:20:3C"
        }
    },
    "startssl-class1-sha2": {
        "fingerprints": {
            "sha-1": "C9:B4:9E:76:BF:A9:AD:74:3A:E8:97:39:EC:B8:E4:87:C2:AC:67:5B",
            "sha-2": "1E:89:94:39:78:1B:8B:75:18:80:90:8B:A9:E3:1E:A2:74:1D:64:38:4F:37:EC:00:3B:97:72:2D:8F:38:05:40"
        }
    }
}

I'm not sure exactly how we'd want to name the different certificates. Maybe even include an item in then JSON with a URL to download the cert.

[jonnybarnes]

In fact do we need the fingerprints of the SHA-2 signed intermediaries? If they already have one then we can just put a big green "Nice" on the page.

[jonnybarnes]

Started a repo collecting fingerprints of these certs: https://github.com/jonnybarnes/sha-stuff

[konklone]

@jonnybarnes I'd welcome putting that dataset to use here, and using it to show users where to go to update their intermediates immediately upon testing their site.

One quibble - for the "fingerprints" fields, I think "sha256" is a more precise field name than "sha2", since you're actually using a specific algorithm (assuming you're running SHA-256 to do it).

[jonnybarnes]

@konklone yup to SHA-256, openssl x509 -in file.crt -noout -fingerprint -sha256 is how I'm getting the value.

[fedoraptor]

Hi guys and @jonnybarnes, I am just passing around here and asking you - isn't it much easier to get/collect CA certificates by exporting them from current java cacerts and/or system CA stores? Like these in CentOS:
/etc/pki/ca-trust/extracted/java/cacerts
or
/etc/pki/ca-trust/extracted/java/ca-bundle.trust.crt

From java cacerts you can use keytool to list them, parse output using sed and grep, export one by one using keytool to pem format and finally use in this tool...

Even more simplified is cutting ca-bundle.trust.crt which is already pem encoded. Currently I have 194 CA certs there...

Maybe it is too late comment for this tool, but might be helpful for somebody passing around, like me ;-)