I have created a kubernetes cluster on aws using kops.
Unless I am wrong, the ca.crt and ca.key files are in the following locations as indicated by this very helpful answer:
- s3://<BUCKET_NAME>/<CLUSTER_NAME>/pki/private/ca/*.key
- s3://<BUCKET_NAME>/<CLUSTER_NAME>/pki/issued/ca/*.crt
However, I coulnd't help noticing that in my ~/.kube/config file (which was created automatically by kops), I have an entry named:
certificate-authority-data
whose contents are different than both of the above files.
What is in any case the CA key/crt pairs we should use when issuing client certificates?
Why there are (seemingly) more than one CAs ?
Ok this is weird ... (perhaps for an inexperienced on such issues like me ...)
When I perform:
echo -n <contents_of_the_certificate-authority-data_entry_of_my_kubeconfig_file> | base64 --decode
...I get my ca.crt file ...
Isn't the ca.crt already base64 encoded?
The certificate-authority-data present on your Kubernetes config file is nothing else that your certificate encoded in base64 (It's a lot more practical to have a continuous text string for a configuration file than without the base64 encoding).
Your .crt file is encoded in RSA, not base64. RSA is a secure cryptosystem based on public and private keys (your .crt and .key respectively). Base64, is, at best, useful for formatting or transmitting already encrypted data.
Related
I'm struggling to setup a kubernetes secret using GoDaddy certs in order to use it with the Ingress Nginx controller in a Kubernetes cluster.
I know that GoDaddy isn't the go-to place for that but that's not on my hands...
Here what I tried (mainly based on this github post):
I have a mail from GoDaddy with two files: generated-csr.txt and generated-private-key.txt.
Then I downloaded the cert package on GoDaddy's website (I took the "Apache" server type, as it's the recommended on for Nginx). The archive contains three files (with generated names): xxxx.crt and xxxx.pem (same content for both files, they represent the domain cert) and gd_bundle-g2-g1.crt (which is the intermediate cert).
Then I proceed to concat the domain cert and the intermediate cert (let's name it chain.crt) and tried to create a secret using these file with the following command:
kubectl create secret tls organization-tls --key generated-private-key.txt --cert chain.crt
And my struggle starts here, as it throw this error:
error: tls: failed to find any PEM data in key input
How can I fix this, or what I'm missing?
Sorry to bother with something trivial like this, but it's been two days and I'm really struggling to find proper documentation or example that works for the Ingress Nginx use case...
Any help or hint is really welcome, thanks a lot to you!
This is a Community Wiki answer, posted for better visibility, so feel free to edit it and add any additional details you consider important.
As OP mentioned in comments, the issue was solved by adding a new line in the beginning of the file.
"The key wasn't format correctly as it was lacking a newline in the
beginning of the file. So this particular problem is now resolved."
Similar issue was also addressed in this answer.
The issue is tricky but easy to fix.
The private key file given by GoDaddy is not properly encoded: it is encoded in UTF8 with BOM, so it starts with a byte that shouldn't be there. It is not understood by nginx ingress when ingesting the private key, and leads to the error.
The simple fix is to run the following command to properly encode the private key file:
iconv -c -f UTF8 -t ASCII generated-private-key.txt > generated-private-key-anssi.txt
And then you get the base64 private key as usual:
cat generated-private-key-anssi.txt | base64 -w 0
Now, the ingress properly gets the ssl certificate. In case you need to see the logs of the ingress to see how the CERT is processed, just list pods & logs in the ingress-nginx namespace.
I am experimenting with load balancers on my infrastructure which is protected by letsencrypt.
I followed a blog article https://blog.bigdinosaur.org/finally-moving-to-letsencrypt-with-haproxy-varnish-and-nginx/
which has worked very well the problem I am having is letsencrypt support SAN (Subject Access Names) the script generates the certificates properly but the cat command it uses to automate combining the certificate and the private key does not support having commas in it.
for example the script to run would be le-renew.sh domain.tld,www.domain.tld
This issues the certificate using the normal certbot procedure.
it then attempts to run cat /etc/letsencrypt/live/domain.tld,www.domain.tld/fullchain.pem /etc/letsencrypt/live/domain.tld,www.domain.tld/privkey.pem
This is where it fails with the error of No Such File or directory which is understandable seen as certbot creates the file /etc/letsencrypt/live/domain.tld/fullchain.pem
Is there a way to make the cat script ignore whats between the comma and the slash so it matches certbot's way of doing things?
Sorry if that was a bit of a ramble.
While exporting the multi protocol gateway from datapower, the certificates aren't getting exported. IS there a way by which the certificates from Datapower appliance can be extracted?
I've always thought it was rather stupid of DataPower to not distinguish between public keys (certificates) and private keys. There is really no good security reason to disallow exporting public certs.
There is a workaround. It's rather cumbersome, but it comes in handy. Let's say you have a public cert called cert:///my-public.cer and you need to export it.
Create a DataPower Crypto Cert object that points to it, called CC-my-public.
Go to Administration/Miscellaneous/Crypto Tools and select the tab Export Crypto Object.
Select Certificate in Object Type (it's the only allowed selection), and type in CC-my-public in the Object Name and my-public-export.xml in the Output File name.
Click Export Crypto Object button, and then Confirm.
There will now be a file in the temporary filesystem called temporary:///my-public-export.xml and it will contain a Base64-encoded copy of the certificate.
Yes, to do this you have to go to Administration > Miscellaneous > Crypto Tools, then navigate to the Export Crypto Object tab.
In the Object Name property, just provide the name of the Cerypto Certificate Object that is referring to the certificate in the cert: you want to export.
In the Output File Name property, specify any name followed by .xml (hold that thought, we are still in middle of the process).
After clicking in Export Crypto Object, a new file with the specified file name will be placed under the temporary: directory.
Now it is time for the trick…
Open a text editor of your preference (XMLSpy, Notepad++, Notepad, Text Edit, etc)
Feed the first line of a new text file with the following content:
-----BEGIN CERTIFICATE-----
Open the .xml file that was created during the Export Crypto Object process
Copy the content that is under the element /crypto-export/certificate into your new text file in your local editor (see in bold):
<?xml version="1.0" encoding="utf-8"?>
<crypto-export version="1">
<certificate version="1">MIIEYjCCA0qgAwIBAg[...]IQOHO9nj6QowsSATEWDs==</certificate>
</crypto-export>
Finish the work in your new text file with the content:
-----END CERTIFICATE-----
The final file should look similarly to this:
-----BEGIN CERTIFICATE-----
MIIEYEBhMCVVMxCzAJBgNVBAgTAlRYMQ8wDQYDVQQHEwZBdXN0
jCCA0qgAwIBAgIISQOHO9nj6QowDQYJKoZIhvcNAQEFBQAwejE [...]
aW4xEjAQBgNVBBAgIISQOHO9nj6QowDQYJKoZIhvcNAQEFBQAw
ejELMAkGA1UW50ZWdyYXRpb24gVGVjaG5vbG9naWVzMRYwFAYD
VQQDEw1zZ2EuYXZuZXWEWw==
-----END CERTIFICATE-----
Save the file using extension .cer, .pem, etc
Done! You have exported a certificate from DataPower under the cert: directory.
Before you ask, yes, DataPower is still safe and private keys cannot be exported following this method.
No, only through a Secure Backup (which is encrypted so you can't read it anyway).
You can't export files other than local.
If you need something dummy , you can always create your own by typing "Crypto Tools" in search. only mandatory field is "Common Name (CN)", I think you know rest,it will create file in cert: with extension -privkey.pem.
Thanks.
Imagine I have p12 container of private key and public certificate. When I export p12 public cert to separate .cer file with Java keytool I may click to .cer file and see full cert chain. How may I get that full path programatically?
I made little investigation. I used keytool's print cert -v command and saw property AuthorityInfoAccess with subproperty
accessMethod: caIssuers
accessLocation: URIName: http://.../some.crt
I downloaded that some.crt (it was PEM cert), and again used print cert -v and again saw
accessLocation: URIName: http://.../some2.crt and repeated downloading .crt files and geting parent until reaching root .crt which hasn't such property.
I think, that I should programatically download chain as I described above and provide it to CertPathValidator as shown here.
If I really need to get chain as I described above, is there any libraries already doing this? Is there any way to do it with std lib? I didn't find bouncycastle examples and java's standart library code like
java.security.cert.Certificate[] cchain = keystore.getCertificateChain(alias);
returns one entry for certificate actually having 2 "parents".
Nitpick: you surely mean keytool -printcert (with hyphen, without space, -v not needed here).
A privatekey entry created by Java in JKS or PKCS12 usually contains the full chain, but keytool -exportcert extracts only the leaf cert.
A PKCS12 created by something else may contain the full chain or not, possibly depending on what you clicked when creating it.
If the chain is there, KeyStore.getCertificateChain returns it, and keytool -list -v (here -v matters) shows it.
If a certificate was imported, or reimported, as a trustedcert entry -- usually in JKS, PKCS12 isn't designed for lone certs -- that never contains the chain, so getCertificateChain on that entry won't work, but IIRC CertPathBuilder can build a chain combining multiple trustedcert entries in one store.
If you do need a parent (chain) cert
you don't already have, and the child specifies AIA.caIssuers, then yes using that to fetch is sensible.
I'm pretty sure there is nothing in standard Java (JRE) library that does this for you, at least so far; I don't know about BouncyCastle or anybody else.
I have tried several ways to get some PEM files to be used by CouchDB. I have generated a cert with powershell, exported it with key to a pfx and then used openssl to convert to 2 pem files and installed them in Couch. With this approach it seems to work in IE11, but it doesn't work with firefox or other browsers. Firefox produces this error:
The key does not support the requested operation. (Error code:
sec_error_invalid_key)
I've also gotten a free ssl cert from ssl.com, (they gave me three CRT files) and tried converting it using openssl, but to no avail.
I've also followed the instructions on the page from CouchDB to generate a self signed cert specifically for this purpose, but it will not load the page. (http://docs.couchdb.com/en/latest/config/http.html#config-ssl about half way down)
Has anybody had success with this? How do I get my certs into a format that will play nice with Couch and will all browsers?
UPDATE:
Now I'm getting this error
A PKCS #11 module returned CKR_DEVICE_ERROR, indicating that a problem has occurred with the token or slot.
Not sure if this is a step forward or backwards...
It seems like CouchDB versions predating 1.7 or 1.6 are not able to have intermediate certificates specified for certificate verification. Since you are writing about having received three .crt files, (s)ome of those might be required as intermediate certificate(s). CouchDB not knowing about them can be the cause of your problem.
Apparently, one way to work around this is to concatenate your certificate file along with the intermediate certificate file(s). Simply cat them together like
$ cat yours.crt theirs.crt > couchdb.crt
...and use CouchDB's certfile configuration option to point to couchdb.crt's location.
If you prefer to convert .crt to .pem first, use sth like
$ openssl openssl x509 -in yours.crt -inform der -outform pem -out yours.pem
In a new enough version, you can probably use an intermediate certificate by setting CouchDB's cacertfile option. Have a look at this for further information.