Fork of easypki with my patches. http://git.kilabit.info/easypki/atom?h=v1.0.0 2017-02-12T22:54:16Z 2017-02-12T22:54:16Z Jeremy Clerc jclerc@google.com 2017-02-10T23:13:54Z urn:sha1:06ee1171dee17245e71bb0ddd742c7f95f9bd2cb API now has a store interface so one could choose to store the different files in a database for example. 2016-10-26T07:41:05Z Jeremy Clerc jclerc@google.com 2016-10-26T07:41:05Z urn:sha1:c42a84ae556034b9fe2f9710603b1c10e8c5588f 2016-10-26T07:28:56Z jeremy-clerc jeremy@clerc.io 2016-10-26T07:28:56Z urn:sha1:93992aab4c8c3a4213b06682538a0ad1495fbde8 create intermediate CA certificates + bug fixes 2016-10-26T01:24:24Z Tim Heckman t@heckman.io 2016-10-26T01:20:05Z urn:sha1:9269e3056eb5a66b128df22cec2296f0ccb9547d [easyca] handle CAs, Intermediates, and Client 2016-10-26T01:18:48Z AJ Christensen aj@junglistheavy.industries 2016-10-25T23:00:08Z urn:sha1:ea1891668a36322802b2c8b34bbe85b25d989f74 * Split certificate type handling up, try to re-use operations where possible. * Set the EKUs for client/serverauth on clients, servers, and Intermediate CAs 2016-10-26T00:15:09Z Tim Heckman t@heckman.io 2016-10-25T23:00:08Z urn:sha1:bc210282ea3e468b9bf79878092d1b6479343c62 Also add DigitalSignature to certificates generated. 2016-10-25T08:02:47Z Tim Heckman t@heckman.io 2016-10-22T09:53:28Z urn:sha1:21b2160d55455afcbcf4799cdc2c74db83b69980 **Note**: This change introduces breaking changes to the `easypki` API: * The `GenerateCertificate` function had a typo in its name. It used to be `GenerateCertifcate` (missing an `i`). * The `GenerateCertificate` function now takes a struct as a parameter, making it easier to use. The main reason behind this change was to provide the ability to generate intermediate CA certificates. This will allow people and organizations to use `easypki` to create a multi-layered tree of trust. In addition to that, the ability to set the maximum path length on CA certificates was added to make the keys safer (less prone for abuse). You can now generate intermediate certificates using the `--intermediate` flag. This flag effectively creates a new CA certificate, within the CA, but doesn't overwrite the `ca.crt` or `ca.key` file. Instead, it uses the same logic as regular certificates and saves the cert and key within the `issued/` and `private/` directories respectively. It's suggested that the `--max-path-len` flag be used when generating CA certificates. You can now set the maximum path depth for a CA certificate by using the `--max-path-len` flag. If you want to generate an offline root CA and ensure that your intermediates cannot generate valid intermediate CA certificates themselves, you would set `--max-path-len 1` when generating the root CA. It's recommended to always use this flag when generating CA certificates, otherwise that certificate will be valid for an "infinite" number of intermediate certificates. With the features above added, a few bugs were discovered in the certificates being generated by `easypki`. Specifically we needed to fix some issues with the KeyUsage and ExtKeyUsage settings of the certs. While troubleshooting an issue with Consul, trying to do verification of a TLS chain generated by `easypki`, I ran in to a situation where the certificates were failing to validate. It turns out there were a few issues that caused this to happen. I found an issue on Hashicorp's Vault project referencing a similar issue with CA certificates generated by Vault itself. This guided me to the first bug that needed patching: * https://github.com/hashicorp/vault/pull/852 >Assign ExtKeyUsageAny to CA certs to help with validation with the >Windows Crypto API and Go's validation logic The solution: when generating CAs, we now set the `ExtKeyUsage` to `ExtKeyUsageAny`. This will mark the CA certificate as being valid for any usage. Some X.509 validation systems require that all certificates in the chain contain the requested usage, including in Go. The second was that the server certificates weren't being assigned `ExtKeyUsageClientAuth` causing issues with applications trying to use the certificates as both client and server certificates. The fix is to also give server certificates `ExtKeyUsageClientAuth`. Upon investigation of certificates deployed for public Internet services, it seems that `ExtKeyUsageClientAuth` is pretty common in server certificates. fixes #2 fixes #3 fixes #4 2016-07-29T16:50:32Z jeremy-clerc jeremy@clerc.io 2016-07-29T16:50:32Z urn:sha1:5c2d8b78bf7652d68acacedd91cc33221fa6134f Update main.go easypki repository on import 2016-07-29T12:21:01Z Ilari Lind ilari.lind@iki.fi 2016-07-29T12:21:01Z urn:sha1:f1aff6946c0c3f28b6a5c1e3cd37fdde2a22a176 Fix non-existing repository on import. 2015-09-14T18:21:50Z Jeremy Clerc jclerc@google.com 2015-09-14T18:21:50Z urn:sha1:29e35e997147ed436e1bb95971125ac3adfd236d