Ca certificate name constraints

[jackivanov]

Description

• changes the basic constraints to critical with pathlen:0:

X509v3 Basic Constraints: critical
    CA:TRUE, pathlen:0

• Generates a random id for every deployment and adds the nameConstraints extension to the CA certificate:

X509v3 Name Constraints: critical
    Permitted:
      IP:34.254.198.99/255.255.255.255
      DNS:585d3e61-7be1-5170-b417-e4e5d5b4fa57.algo
      email:585d3e61-7be1-5170-b417-e4e5d5b4fa57.algo   

Motivation and Context

The discussion initially started in #75 and rose up again in #1673

How Has This Been Tested?

Types of changes

• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • emails in usernames are not allowed anymore

Checklist:

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• I have added tests to cover my changes.
• All new and existing tests passed.

[reaperhulk]

Can you tell me a bit more about the purpose of the randomized DNS/email constraints you've implemented here? Is it just so that a constraint for NC/email exists?

Also, even when IPv6 is not active a NC should be imposed for it -- you can do IP:0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0 in excludedSubtrees to prohibit all IPv6.

[jackivanov]

@reaperhulk I didn't want to stick to a static domain like algo.local or something similar, so randomizing is just a placeholder to enable the name constraints explicitly. Thanks for pointing me to IPv6, I've fixed that, and also added an exclusion for all IPv4 range if the SAN is set to a domain.

[reaperhulk]

Ah, okay. So you're using a permitted in all scenarios so that a NC is applied because excludedSubtrees works a bit weirdly for dNSName and rfc822Name. The CA/Browser Forum Baseline Requirements do document the correct excludedSubtrees model for dNSName to be an empty value, but my best guess for rfc822Name is . and it's safer in both cases to just have a positive constraint.

One last question: in the latest commit a positive name constraint is set on dNSName if and only if the subjectAltName type is IP:

  {%- if subjectAltName_type == 'IP' -%}
   ,permitted;DNS:{{ openssl_constraint_random_id }}
   {%- else -%}
   ,excluded;IP:0.0.0.0/0.0.0.0
   {%- endif -%}

Based on our conversation here I expected that a dNSName constraint would be set at all times. Why is it not?

[jackivanov]

If subjectAltName_type is already set to DNS (a user configured the endpoint as a domain name) the dNSName will be set to this domain only. I'm not sure if we need to add a constraint for our own random domain in this case.

Here is what you'll see if the endpoint will be set to a domain:

X509v3 Name Constraints:
    Permitted:
      DNS:algo.com
      email:a806e892-4883-505a-8be7-a47a7f4015bd.algo
    Excluded:
      IP:0.0.0.0/0.0.0.0
      IP:0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0

and here is a regular cloud deployment without domain in the endpoint:

X509v3 Name Constraints:
    Permitted:
      IP:34.244.177.22/255.255.255.255
      DNS:ad41479e-e72d-571f-8d6b-52a50bb5d277.algo
      email:ad41479e-e72d-571f-8d6b-52a50bb5d277.algo
    Excluded:
      IP:0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0

[reaperhulk]

Ah, okay, I understand now. This looks good at this point!