cacertfile vs certstore for portable Erlang TLS certificate validation

Comparison of Loading Mechanisms

In Erlang/OTP's ssl module, the choice between `cacertfile` and `certstore` determines how the trust store is initialized and maintained within a release. Both options support certificate validation via the `verify` option, but they differ in lifecycle and performance.

• cacertfile: Points to a PEM-encoded file bundle containing trusted CA certificates. The module reads and parses this file at runtime (or upon connection initialization). This is the simplest method for portable releases as the bundle can be shipped directly with the application code.
• certstore: Uses a pre-compiled, binary certificate store. This is typically intended to avoid the overhead of parsing large PEM files repeatedly, but it requires the store to be generated (often via `ssl:gen_certstore/2`) and loaded into memory before being passed to the connection options.

Hostname Verification and DNS Resolution

The choice between `cacertfile` and `certstore` does not affect the logic of hostname verification. Hostname verification is performed by comparing the provided hostname in the connection options against the certificate's Subject Alternative Name (SAN) or Common Name (CN). Since DNS resolution is handled separately by the `inet` module, the `ssl` module simply uses the string passed to it for validation; the underlying trust store only provides the root of trust used to verify the signature chain of that certificate.

CA Rotation and Maintenance

The maintenance implications for CA rotation differ significantly based on how the trust store is packaged:

• cacertfile Maintenance: To rotate CAs, you simply replace the PEM file in the deployment. New connections will pick up the updated bundle. This is highly effective for heterogeneous systems where CA bundles might change without requiring a re-compile of the application logic.
• certstore Maintenance: Rotating CAs requires regenerating the binary certificate store. Since the store is pre-compiled, any change to the CA bundle necessitates an update to the release artifact or a logic mechanism to rebuild the store from a new PEM source at runtime.

If the goal is a self-contained release that remains valid across environments, `cacertfile` is generally preferred for its simplicity, whereas `certstore` is optimized for high-frequency connection scenarios where parsing overhead is a bottleneck.