This repository has been archived by the owner on Aug 31, 2021. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
create intermediate CA certificates + bug fixes
**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: * hashicorp/vault#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
- Loading branch information