You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/modules/tls.md
+67-7Lines changed: 67 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -33,7 +33,7 @@ most common features supported. Specifically, it provides:
33
33
the TLS specification, which requires a 16KiB recieve buffer and,
34
34
therefore, 32KiB of heap within mbedTLS, even in the steady-state.
35
35
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
37
37
a precarious position, and so we strongly suggest that TLS connections
38
38
be made only to endpoints under your control, whose TLS configurations
39
39
can ensure that their ServerHello messages are small. A reasonable
@@ -157,7 +157,8 @@ none
157
157
158
158
## tls.socket:hold()
159
159
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.
161
162
162
163
#### Syntax
163
164
`hold()`
@@ -220,7 +221,10 @@ Sends data to remote peer.
220
221
221
222
#### Note
222
223
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.
224
228
225
229
#### See also
226
230
[`tls.socket:on()`](#tlssocketon)
@@ -252,16 +256,16 @@ none
252
256
253
257
## tls.cert.verify()
254
258
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.
256
260
257
261
#### Syntax
258
262
`tls.cert.verify(enable)`
259
263
260
-
`tls.cert.verify(pemdata)`
264
+
`tls.cert.verify(pemdata[, pemdata])`
261
265
262
266
#### Parameters
263
267
-`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.
265
269
266
270
#### Returns
267
271
`true` if it worked.
@@ -318,9 +322,65 @@ at `server-ca.crt` in the root of the nodemcu-firmware build tree. The build scr
318
322
firmware image.
319
323
320
324
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
322
326
use `tls.cert.verify(true)` and use the stored certificate.
323
327
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
+
324
384
# tls.setDebug function
325
385
326
386
mbedTLS can be compiled with debug support. If so, the tls.setDebug
0 commit comments