Enhancement: Add support loading certificates from a custom stream.

[tregubovav-dev]

Problem statement

A short lived certificates and Cloud HSM providers are used in the more and more broader range of modern applications and services. This means that such certificates needs to be loaded from non-file storage or load them much often. Using file storage to update application certificates add additional overhead and complexity, and reduces security especially in shared environments (like public cloud computing or containerized environments).

Proposed solution

Loading certificates from any TStream descendant allows application to load certificates not only from the file storage, but from any custom storage including in-memory storage.
Proposal: To add public properties like CertStream, KeyStream, RootCertStream to the TTaurusTLSSSLOptions class which are mutually exclusive published properties CertFile, KeyFile, RootCertFile and add additional certificates and keys loading logic.

Use-case 1

Application needs uses cloud HSM provider to load server certificates.

Currently possible high-level workflow:

1. Use cloud HSM provider API to load certificate and key to the TMemortStreams
2. Store content of streams to the files
3. Update CertFile and the KeyFile properties in the TaurusTLSServerIOHandler(<your_instance>).SSLOptions to the saved filenames.
4. Start or restart the listener.

High-level workflow with streams:

1. Use cloud HSM provider API to load certificate and key to the TMemortStreams ot it's descendant variables.
2. Assign these variables to the CertStream and KeyStream properies
3. Start or restart the listener.

Use-case 2

Application API to renew or re-issue short-lived certificates from a Certificate Authority using ACME protocol or provided API.

Currently possible high-level workflow:

1. Use ACME protocol or an API provided by CA to request and receive a certificate/key pair.
2. Parse obtained artifact to the certificate and key and save them into files
3. Update CertFile and the KeyFile properties in the TaurusTLSServerIOHandler(<your_instance>).SSLOptions to the saved filenames.
4. Start or restart the listener.

High-level workflow with streams:

1. Use ACME protocol or an API provided by CA to request and receive a certificate/key pair.
2. Parse obtained artifact to the certificate and key and save them to the TMemortStreams ot it's descendant variables.
3. Assign these variables to the CertStream and KeyStream properies
4. Start or restart the listener.

Possible issues

• certificate/key pair can be returned in multiple formats (text or binary) needs ability to identify an format or declare certificate format from the stream content, but not a file extension.

P.S.

The similar request was declined by the IndySocket team more than 2 years ago.

[JPeterMugaas]

I am interested in seeing a PR for this.

[tregubovav-dev]

Work on this in progress in the private branch.

[tregubovav-dev]

Work in progress:
Two modules for supporting this functionality are merged into main branch now:

• Source/TaurusTLS_SSLContainers.pas
  The module implements set of interfaces, classes and helpers to:
  • keep SSL/TLS configuration in memory
  • implements interface for accessing this data from OpenSSL functions using BIO API
  • protect sensitive data like private keys in encrypted form
• Source/TaurusTLS_Encryptors.pas
  The unit implements set of classes to encrypt/decrypt sensitive data used by interfaces and classes in the Source/TaurusTLS_SSLContainers.pas unit.