roots are handled differently because they're their own CAs
also adds test cases for each of:
- a lone leaf
- a lone intermediate
- a lone root
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
Fixes when the certificate chain does not have a root CA,
in which case the chain should contain all available intermediates
and ca.crt should contain the rootmost certificate.
Co-authored-by: Josh Van Leeuwen <joshua.vanleeuwen@jetstack.io>
Signed-off-by: Wilson Júnior <wilsonpjunior@gmail.com>
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
see also https://github.com/jetstack/cert-manager/issues/4142
EncodeX509Chain checked for self-signed certs by comparing the subject
and issuer of the cert in question, which is invalid since it's
perfectly fine for those to match.
the correct behavior is to use cert.CheckSignatureFrom(cert). this bug
was exposed in 1.4 when ParseSingleCertificateChain started using
EncodeX509Chain in the critical path of several issuers; when end-users
had leaf certificates with subjects matching their issuer's subject, the
bug was triggered.
includes newly written tests for EncodeX509Chain and a test for
ParseSingleCertificateChain
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
Note that using ed25519 on the public internet is not currently
recommended, since it's not widely supported. You'd likely not be able
to use an Ed25519 cert with an ACME issuer today.
Ed25519 certs might be useful for internal PKI, though - an ed25519 CA
issuer, say - or for testing ed25519 certs before they become more
widely available on the public internet. They're not currently
supported by Vault, Venafi or ACME (Letsencrypt) issuers.
Signed-off-by: Anner J. Bonilla <abonilla@hoyosintegrity.com>
Signed-off-by: Anner J. Bonilla <annerjb@gmail.com>
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
also adds/improves doc comments on related functions, and adds tests of
comparisons RSA keys and ECDSA keys. these tests failed as expected
before the function was changed, e.g.:
```text
Executing tests from //pkg/util/pki:go_default_test
---------------------------------------------------
--- FAIL: TestPublicKeysEqualECDSA (0.00s)
generate_test.go:492: got an incorrect match from different curves:
pub1 type: "P-256"
pub2 type: "P-521"
--- FAIL: TestPublicKeysEqualRSA (0.00s)
generate_test.go:560: got an incorrect match from different RSA keys:
pub1: &rsa.PublicKey{N:2293...<snip>...8869, E:65537}
pub2: &rsa.PublicKey{N:2293...<snip>...8869, E:3}
```
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
As discussed in #3847, I went too fast and /lgtm from my bed. That led
to having a piece of code that could potentially break people's
cert-manager deployments.
Our plan is to have the same PR re-opened so that we can have it
released for v1.4 (due on Friday 11 June 2021 as per our timeline).
Signed-off-by: Maël Valais <mael@vls.dev>
it's conceivable that in the future we could have Ed25519 certs,
which would also have a key size of 256 but would be a new named entry
here
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
Found by running this command:
codespell -S .git,*.png,go.sum -L keypair,iam,ans,unknwon,tage,ths,creater
Signed-off-by: Mateusz Gozdek <mgozdekof@gmail.com>
