You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

Difference between revisions of "PKI/Policy"

From Wikitech-static
< PKI
Jump to navigation Jump to search
imported>Jbond
imported>Muehlenhoff
(→‎When to create a new intermediate CA: Typos and also mention Ganeti)
 
(One intermediate revision by one other user not shown)
Line 15: Line 15:


=== When to create a new intermediate CA ===
=== When to create a new intermediate CA ===
We should create a new intermediate CA for every unique services that requires TLS terminations this means for example that we would have separate intermediate CA’s for e.g. debmonitor, database connections, backups etc.  Engineers should use the default profiles and options unless there is a reason not to.  e.g. the expiry time is to short as we can easily restart services
 
For systems or services which just need a certificate to expose an https end point internally such as services set up with [[DNS/Discovery]] records.  Then the advice is to just use the discovery intermediate CA.
 
If you want to set up a service which requires mutual TLS via client auth then you should set up a new intermediate CA for that specific service. This means that a compromise to one mutual TLS client certificate doesn't give access to all client auth protected services.  Currently debmonitor is the only such services to have its own dedicated CA, however over time i can envisage similar intermediate CA's for services such as database connections, backups, Ganeti and possibly some of the hadoop realms.


=== certificate parameters (defaults) ===
=== certificate parameters (defaults) ===
Line 50: Line 53:
== CA Bundles ==
== CA Bundles ==
Ca bundles are maintained and available via http://pki.descover.wmnet/bundles/$ca.pem.  Please not the short comings we currently have around bundles and intermediated certificates documented on the [[PKI/root_ca#Renewing_a_new_intermediate | Root ca page]]
Ca bundles are maintained and available via http://pki.descover.wmnet/bundles/$ca.pem.  Please not the short comings we currently have around bundles and intermediated certificates documented on the [[PKI/root_ca#Renewing_a_new_intermediate | Root ca page]]
[[Category:SRE Infrastructure Foundations]]

Latest revision as of 13:21, 30 June 2021

ROOT CA

The root CA is managed on a dedicated server. New intermediated certificates need to be created on this server and copied into puppet manually as described on the root CA page

Certificate Parameters

The root Ca is configured with the following parameters

  • Algorithm: ecdsa-with-SHA512
  • Size: 521
  • Key Usage: Certificate Sign, CRL Sign
  • pathlen: N/A
  • Expiry: 10 years

Intermediate CA

The intermediate CA's are managed via puppet with the private key distributed via the puppet private repo. Hosts with a puppet agent certificate are able to requests certificates via the cfssl api at https://pki.descover.wmnet:8888 or by using the puppet profile profile::pki::client


When to create a new intermediate CA

For systems or services which just need a certificate to expose an https end point internally such as services set up with DNS/Discovery records. Then the advice is to just use the discovery intermediate CA.

If you want to set up a service which requires mutual TLS via client auth then you should set up a new intermediate CA for that specific service. This means that a compromise to one mutual TLS client certificate doesn't give access to all client auth protected services. Currently debmonitor is the only such services to have its own dedicated CA, however over time i can envisage similar intermediate CA's for services such as database connections, backups, Ganeti and possibly some of the hadoop realms.

certificate parameters (defaults)

  • Algorithm:ecdsa-with-SHA512
  • Size: 521
  • Key Usage: Certificate Sign, CRL Sign
  • pathlen: 1
  • Expiry: 5 Years

Default signing policies

By default intermidiate CA's are use the following defaults for all signing requests.

The defaults can also be overridden by specifying a profile to use. by default we configure additional ocsp and server profiles

Overtime we hope to reduce the expiry down to 24 hours however we would like to get more operational experience first

OCSP profile

This policy is only used for creating the ocsp signing certificate for the specific intermediate CA

  • Key Usage: digital signature, ocsp signing
  • Expiry: 43800h

Server profile

This policy is only used for creating the ocsp signing certificate for the specific intermediate CA

  • Key Usage: digital signature, key encipherment, server auth
  • Expiry: 4 weeks

OCSP Responder

Currently the OCSP responder runs on the same host as intermediate signing server. We currently maintain a patch so that the ocsp refresh services is able to work with the same databased used but cfssl-multirootca

CA Bundles

Ca bundles are maintained and available via http://pki.descover.wmnet/bundles/$ca.pem. Please not the short comings we currently have around bundles and intermediated certificates documented on the Root ca page