Uploaded image for project: 'Puppet Server'
  1. Puppet Server
  2. SERVER-2338

PuppetCA should issue certs with Subject Alternative Name containing the CN for compliance with RFC 2818

    XMLWordPrintable

Details

    • Improvement
    • Status: Resolved
    • Normal
    • Resolution: Fixed
    • SERVER 5.3.5, SERVER 6.0.0
    • SERVER 6.15.3, SERVER 7.1.0
    • None
    • None
    • Enhancement
    • Hide
      When the Puppetserver now signs any incoming CSR, it will always add an extension for subject-alternative-name, or SAN, when signing. Then SAN extension will always contain AT LEAST the Common Name, or CN, as a dns-name on the certificate.

      In the case when the certficate signing request, or CSR, comes with its own SAN extensions, the Puppetserver will sign those that came with the request and ensure that the CN for the CSR is also included in the SAN extension.
      Show
      When the Puppetserver now signs any incoming CSR, it will always add an extension for subject-alternative-name, or SAN, when signing. Then SAN extension will always contain AT LEAST the Common Name, or CN, as a dns-name on the certificate. In the case when the certficate signing request, or CSR, comes with its own SAN extensions, the Puppetserver will sign those that came with the request and ensure that the CN for the CSR is also included in the SAN extension.
    • Needs Assessment

    Description

      Recently Chrome 58 was released and https://www.chromestatus.com/feature/4981025180483584 states the following:

      RFC 2818 describes two methods to match a domain name against a certificate - using the available names within the subjectAlternativeName extension, or, in the absence of a SAN extension, falling back to the commonName. The fallback to the commonName was deprecated in RFC 2818 (published in 2000), but support still remains in a number of TLS clients, often incorrectly.

      Unfortunately this means that PuppetCA-issued certificates are considered invalid by Chrome 58, because by default they don't have the subjectAlternativeName extension and therefore don't include the certificate's common name (CN) as a SAN field.

      The implication is that many (usually internal) services that use PuppetCA-issued certificates as server certificates are now inaccessible with Chrome. Typical examples include Foreman, Puppetboard and other such services. I imagine this is also a problem for PE and its various web interfaces, but we are not PE users so I can't say for sure.

      In order for PuppetCA certificates to be compliant with RFC 2818 the SAN extension should always be added and it should contain at least one DNS: entry matching the certificate's common name (CN) when issuing a new certificate.

      This probably also means that the autosign restriction (which requires the --allow-dns-alt-names flag for puppet cert sign when SANs are present) should be relaxed and only apply when the more than one SAN is present that does not match the certificate's CN.

      Example certificate as it should look:

      Certificate:
          Data:
              Version: 3 (0x2)
              Serial Number: 6 (0x6)
          Signature Algorithm: sha256WithRSAEncryption
              Issuer: CN=Puppet CA: puppet.example.com
              ...
              Subject: CN=foo.example.com
       
              ...
              X509v3 extensions:
                  Netscape Comment: 
                      .(Puppet Ruby/OpenSSL Internal Certificate
                  X509v3 Subject Alternative Name: 
                      DNS:foo.example.com
              ...
      

      Attachments

        Issue Links

          Activity

            People

              tony.vu Tony Vu
              daff Andreas Ntaflos
              Votes:
              6 Vote for this issue
              Watchers:
              21 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Zendesk Support