The configuration of §13.1, with every section annotated. Paths are examples.
# openssl.cnf -- activate the tlsext provider and select its algorithms. openssl_conf = openssl_init [openssl_init] providers = provider_sect ssl_conf = ssl_sect # --- Provider activation (13.1) ------------------------------------- [provider_sect] default = default_sect # 3.7: omitting this leaves the process tlsext = tlsext_sect # without standard algorithms [default_sect] activate = 1 [tlsext_sect] module = /usr/local/lib/ossl-modules/tlsext.so activate = 1 # --- Algorithm selection (13.2) ------------------------------------- # Activation makes algorithms AVAILABLE; these lines make them CHOSEN. [ssl_sect] system_default = system_default_sect [system_default_sect] Groups = tlsext256:x25519:secp256r1 CipherSuites = TLS_TLSEXT_AEAD_TLSEXT_HASH256:TLS_AES_256_GCM_SHA384
For a deployment whose requirement is mandatory rather than preferred (§6.4, §14.2). Note that rollback from this configuration requires restoring the algorithm lines, not merely deactivating the provider (§13.6).
[system_default_sect] Groups = tlsext256 CipherSuites = TLS_TLSEXT_AEAD_TLSEXT_HASH256
The order of §14.5. Each command answers one question; taking them in order is faster than reasoning backwards from a failed handshake.
# 1. Is the provider loaded?
openssl list -providers
# 2. Does it advertise the algorithm, and under what name?
openssl list -digest-algorithms -provider tlsext
openssl list -cipher-algorithms -provider tlsext
openssl list -key-exchange-algorithms -provider tlsext
# 3. Does the property query admit it?
openssl list -digest-algorithms -propquery 'provider=tlsext'
# 4. Which groups and suites are offered?
openssl ciphers -v -tls1_3
openssl s_client -connect host:443 -tls1_3 -groups tlsext256 </dev/null
# 5. What was actually negotiated? (14.2 -- established is not sufficient)
openssl s_client -connect host:443 -tls1_3 </dev/null \
| grep -E 'Cipher|Server Temp Key|Negotiated'
Step 5 is the one that is usually skipped. A successful connection proves a handshake completed, not that it used the intended algorithms. Confirming the negotiated suite and group is the difference between testing the deployment and testing TLS.
| Symptom | Likely cause | Section |
|---|---|---|
Provider absent from list -providers | Wrong module path, or activate not set | 13.1 |
| Provider listed, algorithms absent | Query function not answering that operation id | 7.3 |
| Algorithms listed, never negotiated | Missing capability entry, or not named in Groups/CipherSuites | 10.1, 13.2 |
| Works in the tool, not in the application | Different library context | 13.3 |
| Standard algorithms stop working | default not activated, or a broad property default | 3.7, 14.4 |
handshake_failure at ServerHello | No shared suite or group; peer lacks the code point | 12.3 |
Failure after ServerHello | Suite selected, algorithm not fetchable | 12.3 |
| Failure at Finished | Transcript divergence, duplication bug, or schedule width | 9.2, 15.3 |
| Record-length errors | Missing AEAD algorithm parameters | 8.3 |
| HKDF wrong from the first step | blocksize not reported | 9.3, 15.3 |
| Intermittent resumption failures | Session cache not recording the hash | 15.5 |
| Connection succeeds, requirement unmet | Property expressed as preferred, not required | 14.2 |
The last row has no error message, which is why it is last and why Chapter 19 makes its negative test mandatory.
CFLAGS = -O2 -Wall -Wextra -fPIC $(shell pkg-config --cflags libcrypto)
LDFLAGS = -shared $(shell pkg-config --libs libcrypto)
tlsext.so: provider.o ctx.o cipher_aead.o digest.o keymgmt_ec.o \
keyexch_ec.o signature.o capabilities.o params.o
$(CC) $(LDFLAGS) -o $@ $^
install: tlsext.so
install -m 0755 tlsext.so /usr/local/lib/ossl-modules/
The module links only against libcrypto (requirement N3). It does not link
against libssl, and the absence is structural rather than incidental: a provider
supplies algorithms to libcrypto, and the TLS library consumes them from there
(Chapter 5).