Hi Guys,
Running the latest version of rancher 2.x, when you try and add a cert to the cert store in rancher by going to:
https://rancher.example.co.uk/p/local:project-4p6m4/certificates/add
It gives you:
Private Key is invalid. Please make sure it is a RSA key.
If you look at the greyed out text its asking for:
Paste in the private key starting with -----BEGIN RSA PRIVATE KEY-----
Now RSA private keys do not say that for one… they say:
-----BEGIN PRIVATE KEY-----
But even if you stick in what it says, it still errors so this isn’t just a cosmetic thing.
These keys are 100% valid and also RSA, they are my usual 3 year AlphaSSL cert/key, I have even tested by copying/passing and decoding the cert myself and its fine. I have even read the original files just to make sure and they also give the same error.
Without this working, I can’t setup the ingress.
What I ideally need is LE support and also own paid real certs, is there an alternative way to make this work in rancher?
Kind Regards
Update
Just found: Add certificate error · Issue #13156 · rancher/rancher · GitHub doh. Converting keys now, always believed PEM format used RSA, seems not.
Update
Confirmed, converting key to PKCS#1 resolved the issue.
I do suggest getting std PEM format working out of the box especially from my understanding PKCS#1 is very old which is why I’ve not come across this format before.
1 Like
RSA is the encryption algorithm, PEM is the encoding that the parameters for the encryption algorithm are written out with. The difference is identifying it as RSA is in the base64-encoded body instead of the header. We can support PKCS#8 in the UI too once the backend support is added to parse it, but PKCS#1 is very common (e.g. what you get from openssl genrsa -out some.key 2048 by default) and old doesn’t mean not used.
I’ve get this issue using the generated cert/key from Cloudflare UI, that on Rancher v1 works fine, just copy/paste.
Bus now on v2 I need do this “trick” to be able to use this key.
Agree old doesn’t mean not used but IMO you should be supporting the majority not the minority. Even if your only supporting this you should detect PCKS#8 and provide a suitable error message.
I’ve already said we will support it, but PKCS#1 is by far the most common way private keys are stored (except maybe in Windows, where they mostly use “.pfx” files with encrypted content, which is PKCS#12).
PKCS#8 is the exception, as is a provider giving you a key to use in the first place. Basic use of a public CA is generate your own key locally, with tools like openssl, which are going to give you PKCS#1 unless you do work to make it not. Then give them the CA only the CSR, from which they can issue the cert.
It may make sense for CloudFlare’s use-case where their job is to man-in-the-middle you anwyay, but in general having someone on the internet generate a key for you, trusting them not to store a copy of it, then sending it to you over the internet is not a great practice.
1 Like
Hi Vincent,
I must admit I stand corrected and is an error on my part. I make quite a few certs every month (20+) at work and can confirm after closer examination the ones we create ourselves (CSR which are sent to a certain provider for paid certs) are indeed PKCS#1. It seems the cert which I was using for testing was generated via some third parry portal as it’s a dev cert which some dev arranged and its PKCS#8 like you said.
However all said and done, still would be nice with maybe a modified error message saying that, OK yes it’s invalid but are expecting X, that way ppl would instantly know whats wrong. You don’t necessarily have to cover all others but would be nice obviously.
Apologies for the noise and thanks for the info.