New CA verification functions

[hdrut]

Hi all,

I am trying to understand the purpose of the newly introduced SSL functions. Perhaps I don't fully get the verification process yet...

As far as i know, an SSL client verifies the authenticity of an SSL server by using a Public Key (aka Certificate) signed by a CA. This public key is freely distributed so all peers can decrypt the server's certificate and check its authenticity (i.e it was indeed signed by a recognised Certification Authority, and thus all data therein contained can be trusted, particularly the server's identity).

On the other side, an SSL connection can be set to request client's authenticity verification, though this is not usual (think of a bank transfer or an online payment: only the customer, who is transferring money, needs to check the identity of the other peer).

Going back to the subject, can anybody explain the difference between:

espconn_secure_ca_enable: Enable SSL CA (certificate authenticate). Can be set to SERVER/CLIENT or BOTH (?).
espconn_secure_cert_req_enable: Enable certification verification function when ESP8266 runs as SSL client. Uses esp_cert_private_key.bin file (this I don't get).

Especially: why does the latter require a Private Certificate for validation? Is it being used for signing the client's certificate?

I understand that so far we had used only a single key-pair, and that perhaps now you are deploying two different set's of key-pairs.
Please explain.


Thanks for your support!

King regards,


Horacio

[Npt]

I haven't had the time to test the new functions yet, so I'm speculating here. I don't think that the private key in the API has anything to do with signing certificates. I mean why would the ESP want to sign anything? It does verify signatures (when someone produces a certificate that the ESP doesn't know, but is signed by a CA whose certificate the ESP trusts) but that doesn't require a private key.
So my guess would be that whenever an API functions takes only a certificate, it's for identifying the ESP's communication partner, whereas if a function takes both a certificate and a private key, they form a pair, which means that the certificate is used to identify the ESP itself.
Based on this assumption, we would have this:

1. espconn_secure_set_default_certificate/espconn_secure_set_default_private_key
   ESP=server, certificate identifies the ESP
   (This functionality was already present in 1.3.0 but now it's exposed via the API. Before 1.4.0 you had to write to some undocumented global variables.)
2. espconn_secure_cert_req_enable(0x01,*)
   ESP=client, certificate identifies the ESP
3. espconn_secure_ca_enable(0x01,*)
   ESP=client, certificate identifies server (via CA)
4. espconn_secure_ca_enable(0x02,*)
   ESP=server, certificate identifies client (via CA)

Again, I'm just guessing here based on the presence or absence of a private key. If I'm wrong, feel free to correct me. I've tested numbers 1 and 3, so I'm pretty sure I got those right at least.

[hdrut]

Thks Npt,

I will try those and let you know what I might find.

Greetings,


Horacio

[Npt]

I changed number 2 in my list because I think I made a mistake there. According to this viewtopic.php?f=51&t=1025 the second parameter of espconn_secure_cert_req_enable is esp_cert_private_key.bin which is created by concatenating a certificate and a private key. So it seems it's in fact the ESP (=client) that is to be authenticated in this case.

I'm also very unsure about what I guessed in number 4 (espconn_secure_ca_enable(0x02,*)) because page 9 of the SSL user manual states that bi-directional verification is supported when the ESP is the client (implying that it isn't when it's the server). But what else can the certificate passed to this function be used for? Is it perhaps the certificate chain from the CA (which the client knows ans trusts) to the (ESP=server)'s certificate?