[FEAT] Encode the ca certificate to base64. Instead of having the world dealing with it.
Opened this issue · 1 comments
Is your feature request related to a problem? Please describe.
As already discussed in #452#issuecomment-1767121354 the implementation is not good for no real reason, just because it is implemented by some dependency.
Describe the solution you'd like
The Vault-action should expect a pem formatted certificate and encode it if needed. The problem i see is, that everyone needs to implement the base64 encoding during runtime or during bootstrapping of the environment. Makes documentation and usage more cumbersome. In some cases it could even make the reusability of the ca certificate during the runtime more complicated to decode the certificate again for other steps in the workflow.
Describe alternatives you've considered
To not have a breaking change, maybe it would make sense to check if the file is base64 encoded or not and do necessary conversion if needed. For example it could be checked if the first line matches the pem format string -----BEGIN CERTIFICATE-----.
Very much this!
It's a speed bump having to figure out exactly how to get this done even. At first I thought this is what's needed
openssl x509 -in my.cert -outform der | base64
Interestingly, it seems PEM format, is already base64 formatted. So this changes nothing except stripping the header and footer (BEGIN and END lines), and putting all the base64 data on a single line!
But turns out, what is actually needed is a double-base64 encoded file. i.e. We simply need to encode the cert AGAIN to base64 like so
base64 -i my.cert
And use the resulting string in github secrets. I do not think this is needed for any real reason. I'm guessing the developer thought GH secrets do not support multi-line secrets, but they do. IMO, this is confusing and should be removed