This repository has been archived by the owner on Aug 31, 2021. It is now read-only.
easypki doesn't allow you to create intermediate CAs #2
Comments
This was referenced Oct 23, 2016
|
Hey Tim, Yes it lacks some functionalities, I wrote it in my early early Go dev times to avoid using openssl bash scripts, and it has never been intended for production use :) I also never took the time to enhance it. But this is a good idea and I saw your modifications in your fork, it looks good, feel free to send the PR and I will merge it. Thanks very much. |
theckman
referenced
this issue
in theckman/easypki
Oct 25, 2016
**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 google#3 fixes google#4
|
@jeremy-clerc thank you for getting back to me so quickly, and I'm sorry for the radio silence. Busy weekend / Monday! I've opened a PR for this and the other two issues: #5. |
|
Thank you. This could be for another bug, but could it be interesting to be able to generate client/server certificates based on the intermediate CA instead of the root CA ? |
jeremy-clerc
pushed a commit
that referenced
this issue
Oct 26, 2016
[easyca] handle CAs, Intermediates, and Client
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hey there,
I was looking to use
easypkito create a CA that has the intent of becoming an offline root CA. When I went to begin creating intermediate certificates from the root CA, it became apparent thateasypkilacked the ability to do so. At the same time, I noticedeasypkialso doesn't allow you to set theMaxDepthLen, which is something you may want on a root CA and probably on an intermediate.I've preempted the
CONTRIBUTING.mdfile, slightly, by making modifications toeasypkito unblock myself. Because of there only being certain fields available in the*x509.Certificatestruct, I believe this does require a breaking change in the API. It is mildly convenient becauseGenerateCertifcateis missing aniin certificate anyhow, so we can also fix that typo!For the user, I've implemented the above as two flags:
--intermediate- tellseasypkito generate an intermediate--max-depth-len- sets the pathLenConstraint in the Basic Constrains standard extensionI'm happy to open a PR if you'd like to see the implementation or I am happy to discuss it more in this issue.
The text was updated successfully, but these errors were encountered: