Skip to main content

Overview

Edge Scripting supports the client side of the Node.js node:tls module, so a script can open an outbound TLS connection and speak any protocol over it, not just HTTP. It also gives you access to things fetch() hides: the peer certificate, the negotiated protocol and cipher, and the ability to present a client certificate or pin a specific server certificate. For HTTP and HTTPS endpoints, prefer fetch().

Quickstart

Opens an outbound TLS connection and reports whether the certificate was trusted. tls.connect() verifies the server certificate against the public root CAs; the callback runs once the handshake completes, and socket.authorized reports whether the chain was trusted:
Always set servername so the server receives the SNI it needs to select the right certificate.

Importing the module

The module exposes the following client-side API:

Certificate verification

If you must use node:tls against an origin with a private CA or a missing intermediate, supply the certificate yourself with the connection’s ca option:

Examples

Example 1: SSL checker

fetch() verifies certificates but never shows them to you. With node:tls you can open the connection yourself, wait for the handshake, and read what the server presented. This script exposes an endpoint that returns a JSON report about a host’s certificate: who issued it, which names it covers, when it expires, and whether the chain is trusted. Point a monitor at it to be warned before a certificate runs out.
Calling /?host=example.com returns something like:
A few notes on the code:
  • rejectUnauthorized: false is used here on purpose. This endpoint only reports on a certificate and never sends data to the host, so completing the handshake for an untrusted certificate is safe and lets the report explain the failure through authorized and authorizationError. Do not use this option when you actually talk to the origin.
  • Always set servername so the server receives the SNI it needs to select the right certificate. Without it, hosts serving several sites return their default certificate.
  • The endpoint answers 503 when there is a warning, so an uptime monitor can alert on the status code without parsing the body.

Example 2: Certificate pinning

Standard verification accepts any certificate a public CA is willing to issue for a hostname. If you send credentials to a sensitive origin, you may want to go further and only accept the exact certificate you expect. fetch() gives you no access to the peer certificate, but tls.connect() lets you pass your own checkServerIdentity function, which runs during the handshake before any application data is sent. The function below first performs the standard hostname check, then compares the certificate’s SHA-256 fingerprint to a pinned value stored as an environment secret. Returning an Error aborts the connection:
Pinning trades flexibility for assurance: when the origin rotates its certificate, the pin must be updated or requests start failing. Pin the fingerprint of a longer-lived intermediate CA (compare cert.issuerCertificate.fingerprint256) if the origin renews its leaf certificate often.

Example 3: Client certificates (mTLS)

If the server requires a client certificate, pass the PEM-encoded cert and key in the connection options, read from environment secrets:
If you have trouble storing a multi-line PEM value in a secret, store it base64-encoded instead and decode it in the script with atob(process.env.ClientCert).
For HTTPS origins that require mTLS, use fetch() with Deno.createHttpClient instead. See Client Certificates on the HTTPS page.

References

Last modified on August 18, 2026