/kind bug
What happened:
I followed the tutorial: https://github.com/jetstack/cert-manager/blob/master/docs/user-guides/ca-based-issuer.md
After I've created the secret and the issuer it throws an error: Error getting keypair for CA issuer: certificate is not a CA
What you expected to happen:
It reads the keypair successfully
Environment:
kubectl version): 1.9I seem to think that I am hitting the same issue here. Does the key / cert need to be base64 or something?
It sounds like the certificate you provided is not a CA certificate?
A Certificate Authority certificate is not just any certificate. It has to say it is a CA certificate and that it has the ability to sign other certificates. No real CA is going to sign your CA certificate, so it has to be a root certificate too (so self-signed).
Here's one guide for creating your own CA certificate:
https://coreos.com/os/docs/latest/generate-self-signed-certificates.html
You are right that data values in Secrets are stored in base 64, but kubectl create secret will do that for you.
@whereisaaron I think that would work to, and be much easier.
It turns out that on MacOS the default OpenSSL config does not include the configuration for v3_ca certificate generation. When you follow the directions on the cert-manager site as well as most other sites which reference open ssl, they do not work. The Key for me was adding:
[ v3_ca ]
basicConstraints = critical,CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
To the /etc/ssl/openssl.cnf file. And then adding -extension v3_ca to the open ssl cert generation. Perhaps this will help others.
You're right @mmacfadden, the instructions are insufficient, you need to add those OpenSSL settings to the certificate creation. You could propose a PR for the documentation page, or prevail on @munnerz to add your instructions.
it works with @mmacfadden solution only without one change. You should append -extensions v3_ca in Mac OS.
If you don't want to modify your /etc/ssl/openssl.cnf you can also just create a copy and reference it with the -config option, like so:
cp /etc/ssl/openssl.cnf openssl-with-ca.cnf
Append the 4 lines mentioned in the comment above to your local copy using your favorite text editor.
openssl req -x509 -new -nodes -key ca.key -sha256 -days 1024 -out ca.crt -extensions v3_ca -config openssl-with-ca.cnf
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle rotten
/remove-lifecycle stale
when on macOS, generally, alternative version of openssl is installed via homebrew.
in that case using -config /usr/local/etc/openssl/openssl.cnf works, without any modifications.
openssl req -x509 -new -nodes -key ca.key -subj "/CN=${COMMON_NAME}" -days 3650 -reqexts v3_req -extensions v3_ca -out ca.crt -config /usr/local/etc/openssl/openssl.cnf
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to jetstack.
/close
@retest-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.
Send feedback to jetstack.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Can we add @anapsix 's answer to docs ?
Seems, it only helps on Mac.
/reopen
@AmazingTurtle: You can't reopen an issue/PR unless you authored it or you are a collaborator.
In response to this:
/reopen
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
I have the same issue.
I'm using a digicert ssl certificate. They are giving me an intermediate ca and a ssl certificate. I composed them to a valid certificate chain. I'm using the private key from CSR. cert-manager says, it was not a CA. What do I do now?
edit:
oh wait I'm just dumb. RTFM to myself. I'm attaching the keychain directly to my ingress now, completely avoiding cert-manager here because cert-manager tries to create new certificates based on the CA. I just didn't know.
when on macOS, generally, alternative version of
opensslis installed viahomebrew.
in that case using-config /usr/local/etc/openssl/openssl.cnfworks, without any modifications.openssl req -x509 -new -nodes -key ca.key -subj "/CN=${COMMON_NAME}" -days 3650 -reqexts v3_req -extensions v3_ca -out ca.crt -config /usr/local/etc/openssl/openssl.cnfI'm on MaOS and have openssl -> LibreSSL 2.8.3. It seems that authorityKeyIdentifier is not supported.
openssl
OpenSSL> version
LibreSSL 2.8.3
in that case, try using "openssl" binary installed by homebrew instead, @mikereiche
$ brew list openssl | grep bin/openssl
/usr/local/Cellar/openssl/1.0.2t/bin/openssl
$ /usr/local/Cellar/openssl/1.0.2t/bin/openssl version
OpenSSL 1.0.2t 10 Sep 2019
Thanks. I avoided the error by removing the ":always", like this :
authorityKeyIdentifier = keyid,issuer
Most helpful comment
@whereisaaron I think that would work to, and be much easier.
It turns out that on MacOS the default OpenSSL config does not include the configuration for v3_ca certificate generation. When you follow the directions on the cert-manager site as well as most other sites which reference open ssl, they do not work. The Key for me was adding:
To the
/etc/ssl/openssl.cnffile. And then adding-extension v3_cato the open ssl cert generation. Perhaps this will help others.