| Age | Commit message (Collapse) | Author |
|---|
|
|
|
create intermediate CA certificates + bug fixes
|
|
[easyca] handle CAs, Intermediates, and Client
|
|
* Split certificate type handling up, try to re-use operations where
possible.
* Set the EKUs for client/serverauth on clients, servers, and
Intermediate CAs
|
|
Also add DigitalSignature to certificates generated.
|
|
**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
|
|
Update main.go easypki repository on import
|
|
Fix non-existing repository on import.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NextNumber replaces NextSerial to be used by serial+crlnumber
|
|
moved initpki to easyca package
add revoke command and method
|
|
fix serial, supposed to be hexa for openssl compatibility
add index file to be used by oscp daemon, revoke/crl future commands
|
|
|
