1

I want to establish a secure connection with self-signed certificates. I used the following conf file for openssl

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[req_distinguished_name]
countryName = EN
stateOrProvinceName = NY
localityName = New York
organizationName = MyOrg
organizationalUnitName = MyDept

[v3_req]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
basicConstraints = CA:TRUE
subjectAltName = @alt_names

[alt_names]
IP.1 = 10.0.4.70

And generated the certificates running

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout key.pem -out cert.pem -config openssl.cnf

However when my server picks up these certificates I get

[WARNING] 2018/04/14 14:19:09 push_to_system.go:419: sending sample request failed:Post https://10.0.4.70:8090/content/: x509: certificate signed by unknown authority

How do I fix my cert generation to avoid this problem?

2

Sam's Answer may get you working, but is NOT a good idea for production. For clarity I will try to explain why you are getting this.

It is NOT enough to create a set of encryption keys used to sign certificates. Anyone, and you just did, can do this. This is why there are "Trusted certificate authorities" These are entities that known and trusted. An ssl implementation comes with a list of authorities and their public keys to verify that certificates claimed to be signed by them are in fact from them and not someone else claiming to be them..

So when you create your own, any ssl implementation will see that indeed a certificate is signed by you, but they do not know you can be trusted so unless you add you CA (certificate Authority) to the list of trusted ones it will refuse it. SSL is not just about encrypting messages but also verifying that the person you are talking to or the person that has cyptographically signed something IS who they say they are.

IT IS NOT a good idea to wholesale "skip", "bypass" or what not the verification in production as it will accept certificates from anyone, making you vulnerable to impersonation, or man in the middle attacks.

Your problem is NOT with your certificate creation but you configuration of your ssl client. It very clearly told you it refused to connect because it does not know who it is talking to. (this is good)

You must setup your certificate authority as a trusted one on the clients. This is dependent on your setup so more details are needed to help you there. These are another question that try to tackle that issue:

Adding a self signed certificate to the trusted list

Add self signed certificate to Ubuntu for use with curl

Note this will work ONLY for you, if you have third party clients that will be talking they will all refuse your certificated for the same reason, and will have to make the same adjustments. This is why trusted CAs sell the service of signing certificates for applications/servers etc, because they are already in the list and are trusted to verify who you are. So if you pay them to do this, the resulting certificate will be trusted by everyone. :)

reference" https://en.wikipedia.org/wiki/Certificate_authority

| improve this answer | |
0

Can you try a workaround using -tls-skip-verify, which should bypass the error. However, this is only a temp. fix: you should try to address the problem by restarting the openSSL instance - setting up a new certificate and/or rebooting your server.

| improve this answer | |
  • I can't because that would require changing the code (I am running using a golang script, not directly with curl). I am also interested in a permanent fix, not just a bypass :) – Mnemosyne Apr 14 '18 at 12:34
  • Alright, gotcha! Are you sure all information in the config file is correct? – Sam Apr 14 '18 at 12:35
  • Yes, it should be. – Mnemosyne Apr 14 '18 at 12:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.