Allow usage of externally supplied TLS config

[venkyg-sec]

Name of feature:

Externally supplied TLS config for usage by step-ca service.

Pain or issue this feature alleviates:

Step-ca currently makes the assumption that the TLS config/certificate for the server itself would be signed by the same x509 CA used to sign client certificates (via acme, scep etc). This assumption might not scale to all environments - where enterprises may use different CAs for Client and Server side ecosystem.

This PR makes a simple patch by allowing the *tls.Config to be supplied as an Option to the CA interface.

Is there documentation on how to use this feature? If so, where?

Not yet - but happy to update the tests, include examples in the sample application and documentation if this feature is of interest.

Tests

venkyg@venkyg-fedora-PC2HVLQL:~/certificates$ make test
✓  acme (2.705s) (coverage: 64.1% of statements)
✓  acme/api (229ms) (coverage: 92.4% of statements)
✓  acme/db/nosql (12ms) (coverage: 97.0% of statements)
∅  api/models
✓  api/log (2ms) (coverage: 52.9% of statements)
✓  api/render (2ms) (coverage: 83.7% of statements)
✓  api/read (3ms) (coverage: 100.0% of statements)
∅  authority/admin
✓  api (1.593s) (coverage: 76.9% of statements)
∅  authority/administrator
✓  authority/internal/constraints (9ms) (coverage: 81.6% of statements)
✓  authority/admin/db/nosql (28ms) (coverage: 94.8% of statements)
✓  authority/config (33ms) (coverage: 67.5% of statements)
✓  authority/admin/api (63ms) (coverage: 88.3% of statements)
✓  authority/policy (10ms) (coverage: 41.7% of statements)
✓  authority (1.039s) (coverage: 46.1% of statements)
✓  cas/apiv1 (6ms) (coverage: 97.4% of statements)
✓  cas (6ms) (coverage: 95.0% of statements)
✓  ca/identity (24ms) (coverage: 93.3% of statements)
✓  cas/cloudcas (130ms) (coverage: 96.4% of statements)
✓  cas/softcas (507ms) (coverage: 91.3% of statements)
✓  cas/vaultcas/auth/kubernetes (8ms) (coverage: 87.5% of statements)
✓  cas/vaultcas/auth/approle (9ms) (coverage: 86.4% of statements)
✓  cas/vaultcas (14ms) (coverage: 79.7% of statements)
∅  cmd/step-ca
∅  commands
∅  examples/basic-client
∅  examples/basic-federation/client
∅  examples/basic-federation/server
✓  errs (4ms) (coverage: 7.6% of statements)
✓  db (9ms) (coverage: 26.5% of statements)
∅  examples/bootstrap-client
∅  examples/bootstrap-mtls-server
∅  examples/bootstrap-tls-server
∅  monitoring
✓  logging (6ms) (coverage: 30.6% of statements)
✓  policy (12ms) (coverage: 93.0% of statements)
∅  scripts/badger-migration
∅  server
✓  pki (68ms) (coverage: 33.8% of statements)
✓  scep/api (8ms) (coverage: 27.4% of statements)
✓  scep (142ms) (coverage: 5.0% of statements)
✓  webhook (2ms) (coverage: 71.1% of statements)
✓  templates (7ms) (coverage: 93.5% of statements)
✓  cas/stepcas (3.643s) (coverage: 93.9% of statements)
✓  authority/provisioner (14.762s) (coverage: 79.0% of statements)
✓  ca (26.87s) (coverage: 43.0% of statements)

DONE 4351 tests in 38.389s
✓  acme (5.872s) (coverage: 73.0% of statements)

DONE 302 tests in 7.503s
cat defaultcoverage.out tpmsimulatorcoverage.out > coverage.out

💔Thank you!

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[maraino]

Thanks @venkyg-sec, LGTM.
I've fixed the linter issues in your fork.