one way ssl with curl

1

I know there are many topics and articles out there but I am really spinning my wheels on this one.

I have an NodeJS instance running on TLS. I need another server to connect to it using cURL. Unfortunately I am not able to do a -k because of limitations of the version of cURL that I am using.

Therefore I need there to be no certificate warnings when connecting.

My thought are these:

1. to generate a cert 
2. generate a certificate signing request
3. acquire the CA
4. sign the certificate with the CA
5. Configure NodeJS to send the CA, Cert, and Key during handshakes
6. Have the requesting server do a cURL command, specifying the certificate in the command.

Does this make any sense or is this backwards? I have having a lot of trouble differentiating each piece of it.

thanks,

Edit

So apparently I have no idea what I am doing based on responses. If I could obtain a copy of the CA, public, and private keys. How then would I proceed? Please be verbose.

jacksonecac

Posted 2017-08-30T18:38:40.863

Reputation: 111

"I have no idea what I am doing ... How then would I proceed? Please be verbose." - unfortunately this is a very broad requirement, especially considering that you have no idea yet what you are doing currently and don't really specify where do you want to end up. But you might start with searching for introduction ssl and ssl certificate step by step. – Steffen Ullrich – 2017-08-30T19:08:42.653

Answers

2

Unfortunately I am not able to do a -k because of limitations of the version of cURL that I am using.

That is the wrong approach from start. -k disables any validation of the server certificate and thus makes man in the middle attacks easy, i.e. it allows exactly the thing which https is intended to prevent.

  1. Configure NodeJS to send the CA, Cert, and Key during handshakes
  2. Have the requesting server do a cURL command, specifying the certificate in the command.

I'm not quite sure what you are trying to achieve here but if I understand you correctly you want to generate a certificate at the server side and then send this certificate to the client so that it will check against this certificate in the future.

The problem with this approach is that you need to protect the sending of the newly created certificate from the server to the client. Otherwise a man in the middle could just exchange the certificate against one created by the attacker and thus continue to do undetectable man in the middle attacks.

Unfortunately your question describes an attempt to solve an unknown problem (see XY problem). The common way to do SSL is to have a certificate authority (CA) trusted already by the client and a certificate issued by this CA. In most cases a public CA like Let's Encrypt is used for this since these CA are already trusted by the client (ships with OS or browser). There is no explanation in your question why you cannot go this established way and instead need to invent your own solution.

Steffen Ullrich

Posted 2017-08-30T18:38:40.863

Reputation: 3 897