Skip to content

Commit 76e9f1a

Browse files
authored
Document tls.cert.auth (#3010)
1 parent 49f25bd commit 76e9f1a

File tree

2 files changed

+71
-10
lines changed

2 files changed

+71
-10
lines changed

app/modules/tls.c

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -525,7 +525,8 @@ static const char *fill_page_with_pem(lua_State *L, const unsigned char *flash_m
525525
return NULL;
526526
}
527527

528-
// Lua: tls.cert.auth(true / false | PEM data [, PEM data] )
528+
// Lua: tls.cert.auth(PEM data [, PEM data] )
529+
// Lua: tls.cert.auth(true / false)
529530
static int tls_cert_auth(lua_State *L)
530531
{
531532
int enable;
@@ -565,7 +566,8 @@ static int tls_cert_auth(lua_State *L)
565566
return 1;
566567
}
567568

568-
// Lua: tls.cert.verify(true / false | PEM data [, PEM data] )
569+
// Lua: tls.cert.verify(PEM data [, PEM data] )
570+
// Lua: tls.cert.verify(true / false)
569571
static int tls_cert_verify(lua_State *L)
570572
{
571573
int enable;
@@ -579,7 +581,6 @@ static int tls_cert_verify(lua_State *L)
579581
if (lua_type(L, 1) == LUA_TSTRING) {
580582
const char *types[2] = { "CERTIFICATE", NULL };
581583
const char *names[1] = { "certificate" };
582-
583584
const char *error = fill_page_with_pem(L, &tls_server_cert_area[0], flash_offset, types, names);
584585
if (error) {
585586
return luaL_error(L, error);

docs/modules/tls.md

Lines changed: 67 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -33,7 +33,7 @@ most common features supported. Specifically, it provides:
3333
the TLS specification, which requires a 16KiB recieve buffer and,
3434
therefore, 32KiB of heap within mbedTLS, even in the steady-state.
3535
While it is possible to slightly raise the buffer sizes with custom
36-
nodeMCU builds, connecting to endpoints out of your control will remain
36+
NodeMCU builds, connecting to endpoints out of your control will remain
3737
a precarious position, and so we strongly suggest that TLS connections
3838
be made only to endpoints under your control, whose TLS configurations
3939
can ensure that their ServerHello messages are small. A reasonable
@@ -157,7 +157,8 @@ none
157157

158158
## tls.socket:hold()
159159

160-
Throttle data reception by placing a request to block the TCP receive function. This request is not effective immediately, Espressif recommends to call it while reserving 5*1460 bytes of memory.
160+
Throttle data reception by placing a request to block the TCP receive function.
161+
This request is not effective immediately, Espressif recommends to call it while reserving 5*1460 bytes of memory.
161162

162163
#### Syntax
163164
`hold()`
@@ -220,7 +221,10 @@ Sends data to remote peer.
220221

221222
#### Note
222223

223-
Multiple consecutive `send()` calls aren't guaranteed to work (and often don't) as network requests are treated as separate tasks by the SDK. Instead, subscribe to the "sent" event on the socket and send additional data (or close) in that callback. See [#730](https://github.com/nodemcu/nodemcu-firmware/issues/730#issuecomment-154241161) for details.
224+
Multiple consecutive `send()` calls aren't guaranteed to work (and often don't) as
225+
network requests are treated as separate tasks by the SDK.
226+
Instead, subscribe to the "sent" event on the socket and send additional data (or close) in that callback.
227+
See [#730](https://github.com/nodemcu/nodemcu-firmware/issues/730#issuecomment-154241161) for details.
224228

225229
#### See also
226230
[`tls.socket:on()`](#tlssocketon)
@@ -252,16 +256,16 @@ none
252256

253257
## tls.cert.verify()
254258

255-
Controls the vertificate verification process when the Nodemcu makes a secure connection.
259+
Controls the certificate verification process when the NodeMCU makes a secure connection.
256260

257261
#### Syntax
258262
`tls.cert.verify(enable)`
259263

260-
`tls.cert.verify(pemdata)`
264+
`tls.cert.verify(pemdata[, pemdata])`
261265

262266
#### Parameters
263267
- `enable` A boolean which indicates whether verification should be enabled or not. The default at boot is `false`.
264-
- `pemdata` A string containing the CA certificate to use for verification.
268+
- `pemdata` A string containing the CA certificate to use for verification. There can be several of these.
265269

266270
#### Returns
267271
`true` if it worked.
@@ -318,9 +322,65 @@ at `server-ca.crt` in the root of the nodemcu-firmware build tree. The build scr
318322
firmware image.
319323

320324
The alternative approach is easier for development, and that is to supply the PEM data as a string value to `tls.cert.verify`. This
321-
will store the certificate into the flash chip and turn on verification for that certificate. Subsequent boots of the nodemcu can then
325+
will store the certificate into the flash chip and turn on verification for that certificate. Subsequent boots of the ESP can then
322326
use `tls.cert.verify(true)` and use the stored certificate.
323327

328+
## tls.cert.auth()
329+
330+
Controls the client key and certificate used when the ESP creates a TLS connection (for example,
331+
through `tls.createConnection` or `https` or `MQTT` connections with `secure = true`).
332+
333+
#### Syntax
334+
`tls.cert.auth(enable)`
335+
336+
`tls.cert.auth(pemdata[, pemdata])`
337+
338+
#### Parameters
339+
- `enable` A boolean, specifying whether subsequent TLS connections will present a client certificate. The default at boot is `false`.
340+
- `pemdata` Two strings, the first containing the PEM-encoded client's certificate and the second containing the PEM-encoded client's private key.
341+
342+
#### Returns
343+
`true` if it worked.
344+
345+
Can throw a number of errors if invalid data is supplied.
346+
347+
#### Example
348+
Open an MQTT client.
349+
```
350+
tls.cert.auth(true)
351+
tls.cert.verify(true)
352+
353+
m = mqtt.Client('basicPubSub', 1500, "admin", "admin", 1)
354+
```
355+
For further discussion see https://github.com/nodemcu/nodemcu-firmware/issues/2576
356+
357+
Load a certificate into the flash chip.
358+
359+
```
360+
tls.cert.auth([[
361+
-----BEGIN CERTIFICATE-----
362+
CLIENT CERTIFICATE String (PEM file)
363+
-----END CERTIFICATE-----
364+
]]
365+
,
366+
[[
367+
-----BEGIN RSA PRIVATE KEY-----
368+
CLIENT PRIVATE KEY String (PEM file)
369+
-----END RSA PRIVATE KEY-----
370+
]])
371+
```
372+
373+
#### Notes
374+
The certificate needed for proofing is stored in the flash chip. The `tls.cert.auth` call with `true`
375+
enables proofing against the value stored in the flash.
376+
377+
The certificate can not be defined at firmware build time but it can be loaded into the flash chip at initial boot of the firmware.
378+
It can be supplied by passing the PEM data as a string value to `tls.cert.auth`. This
379+
will store the certificate into the flash chip and turn on proofing with that certificate.
380+
Subsequent boots of the ESP can then use `tls.cert.auth(true)` and use the stored certificate.
381+
382+
383+
324384
# tls.setDebug function
325385

326386
mbedTLS can be compiled with debug support. If so, the tls.setDebug

0 commit comments

Comments
 (0)