Requirement F6 asks that the provider be activatable without modifying the application, and
constraint C6 requires that algorithms be available in the library context the
SSL_CTX actually uses. This chapter specifies the configuration and states the
failure modes, which in deployment are more often the cause of trouble than the cryptography
is.
openssl_conf = openssl_init [openssl_init] providers = provider_sect ssl_conf = ssl_sect [provider_sect] default = default_sect tlsext = tlsext_sect [default_sect] activate = 1 [tlsext_sect] module = /usr/local/lib/ossl-modules/tlsext.so activate = 1 [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
Three things are happening here and they are independent. The provider_sect
activates modules. The Groups line sets which groups are offered and in what order,
naming the group by the IANA name from its capability entry (§10.5). The
CipherSuites line sets the TLS 1.3 suite list and ordering (§12.2, requirement 5).
A deployment that activates the provider but omits the last two lines has loaded the algorithms
without asking for them, and will observe a perfectly ordinary standard handshake.
Design. The provider reads its own configuration from its section, so deployment-specific choices — a code point for a closed deployment, a delegate selection — are set here rather than compiled in. Configuration errors are raised at activation, as configuration failures in the sense of §7.7, so that a misconfigured provider fails to load rather than loading in a degraded state.
The distinction in the previous paragraph is worth a section of its own, because it accounts for a large share of "the provider does not work" reports.
Activating a provider makes its algorithms available. It does not make them
chosen. Selection happens by fetch, and a fetch that does not name the algorithm, or
whose property query does not distinguish it, will resolve to whatever the ordinary rules
prefer — typically the default provider's implementation. For the TLS case, selection is driven
by the negotiated parameters, which are in turn driven by the Groups and
CipherSuites configuration above.
The practical test is in two parts: confirm the provider is loaded, then confirm it is used. The two are separate observations and the first does not imply the second.
$ openssl list -providers $ openssl list -digest-algorithms -provider tlsext $ openssl s_client -connect host:443 -tls1_3 </dev/null | grep -E 'Cipher|Group'
Constraint C6 appears in deployment as follows. An SSL_CTX is bound to a library
context when it is created. An application that creates its SSL_CTX against an
explicit context, while the configuration file activates the provider in the default context,
will not see the provider at all — the configuration is correct, the module is present, and the
algorithms are invisible.
Applications that use only the default context, which is the large majority, are unaffected. Applications built around explicit contexts for isolation — including anything using a private context for a FIPS-related purpose — must activate the provider in the context they use, which generally means programmatic loading rather than the configuration file.
When two activated providers offer the same algorithm name, the resolution depends on property query and on ordering. A deployment that wants determinism should not rely on ordering; it should name the provider in the property query (§14) and treat the requirement as mandatory rather than preferred.
The recommendation of §9.5 — that a component claim a distinctive name rather than a standard one — removes this question entirely for the algorithms it applies to, at the cost of requiring explicit configuration to use them. For a deployment whose purpose is to use particular algorithms, that explicitness is a feature.
The module is a shared object loaded into every process that activates it, with the privileges of that process (constraint C5). The deployment consequences follow directly:
A deployment plan should include the reverse operation, and it is simple: set
activate = 0 in the provider section, or remove the section, and restart the
consuming processes. Because the configuration is data rather than code, rollback does not
require rebuilding anything.
The one caveat is the fail-closed behaviour of §6.4. If the deployment has configured the custom suite or group as the only acceptable option, deactivating the provider does not restore standard connectivity — it removes connectivity, which is the intended behaviour of a fail-closed configuration and a surprise to whoever performs the rollback expecting a return to normal. The rollback procedure must therefore restore the algorithm configuration, not only the provider activation.