0

A company's internal CA has issued a root signer cert (there's no intermediate cert acting as signer) in which the DN contains only the C=US and O=company_name and no other DN fields.

The cert signed by this root is used for an IBM MQ instance so the things connecting to it are not comparing the CN to the URI. The one SAN value present matches the cert label in the keystore which IBM defaults to ibmwebspheremq[qmgrname] so the SAN wold not match the URI, the QMgr name, or anything else a connection requestor would expect.

  • The JEE apps connecting to this server using a variety of JEES providers don't complain.
  • OpenSSL validation using s_client succeeds.
  • IBM GSKit fails to validate the personal cert in the local KDB (IBM's keystore format) using this signer. The error cites An invalid basic constraint extension was found with the GSKM_VALIDATIONFAIL_SUBJECT citing the IssuerName and Issuer but shows them with identical values.

I'm wondering whether this DN, in particular the missing CN, is considered non-compliant. Or, more to the point, it obviously works with some crypto providers but should I expect it to fail with any that validate more strictly?

T.Rob
  • 165
  • 9
  • 1
    `openssl s_client` does not do any hostname validation. – Steffen Ullrich Oct 25 '18 at 17:01
  • Thanks. Since the error I got references basic constraints I thought there might be a constraint that CN not be blank either generally or for signer certs in particular. Maybe that's covered in the category of hostname validation but I didn't want to trust my own interpretation of that and have my client rely on it. – T.Rob Oct 25 '18 at 17:40
  • Your terminology is confusing. A 'root' cert normally cannot be used as the cert for a server, or a client; the root cert (_or_ a CA cert) instead _issues_ (signs) the cert(s) for the server(s) and client(s). The error message says the problem is with the 'basic constraints' extension, which specifies CA-vs-non-CA and optionally path limit; it never has anything at all to do with either Subject DN or SubjectAltNames. There is an extension for name constraints, but it only applies to CAs, it is almost never used, and it is entirely different from basic constraints. – dave_thompson_085 Oct 26 '18 at 03:27
  • Thanks @dave_thompson_085, I've updated to clarify. – T.Rob Nov 03 '18 at 03:40
  • @SteffenUllrich: not by default, but since 1.0.2 in 2015 it can. See A. – dave_thompson_085 Aug 03 '19 at 16:55

1 Answers1

3

I'm wondering whether this DN, in particular the missing CN, is considered non-compliant.

Non-compliant with respect to what? Let's take a look at some things it may or may not be compliant with.

X.509

It meets the X.509 spec: from RFC 5280 section 4.2.1.6 Subject (italics mine):

If the subject is a CA (e.g., the basic constraints extension, as discussed in Section 4.2.1.9, is present and the value of cA is TRUE), then the subject field MUST be populated with a non-empty [X.500] distinguished name [DN] matching the contents of the issuer field.

and O=company_name,C=US is a valid X.500 DN, so no non-compliance there.

TLS 1.2

I'm not back-of-my-hand familiar with RFC 5246, but it seems to indicate that server certificates should be validated by the client, but leaves it completely up to the vendor to decide how to do that. So no non-compliance there either.

CA / Browser Forum

The CA/B Baseline Requirements provide the criteria for certificates to be acceptable to a web browser without throwing errors.

I won't quote directly because it's a lengthy document with many references to Subject and SAN attributes, but this matches up with your understanding that the fully-qualified domain name (FQDN) needs to either be in the DN or a SAN. So we've found something that your IBM cert is non-compliant with!

Summary: If you tried to connect to a HTTPS page protected by that cert, your browser would rightlfully throw a facefull of errors because that cert is non-compliant with the CA/B Baseline Requirements.

For any other TLS usage, it's totally fine. In fact, if the purpose is to certify that this is an IBM server operated by company_name, then checking the root CA and an IBM-specific SAN seems like an appropriate way to do it! (With that goal, does it matter what the hostname of the box is, or what URL you used to access it?)

Community
  • 1
Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • Thanks. *"Non-compliant with respect to what?"* I think you covered the bases. The issue for me was whether anything relying on that cert would likely break. Since there are at least half a dozen different JSSE providers in use here, plus GSKit, and I don't have the subject matter expertise to check them all for their respective teams I wanted to check against the specs those providers rely on. I looked for and found the specs you cited but lack the expertise to trust my own interpretation of them and appreciate the help. – T.Rob Oct 25 '18 at 17:36
  • 1
    Cool. Note that when using out-of-the-box JSSE or openssl, the only certificate validation that's done is to check that the signatures are valid and possibly that they chain to a trusted root, if you've configured a trust store. They do not do any DN or SAN validation themselves and instead provide callbacks for the application developer to add their own cert validation logic. TL;DR: whether that cert will be acceptable to all clients depends on how the client is written, and has nothing to do with which crypto provider it's using. – Mike Ounsworth Oct 25 '18 at 17:49
  • @MikeOunsworth: _Sun/Oracle/OpenJDK_ JSSE since j7 (in 2011) _can_ do hostname checking, but it is off by default; see `SSLParameters.setEndpointIdentificationAlgorithm`. IBM Java has different cryptoproviders and I don't know for that. And JSSE doesn't callback for hostname, though higherlevel `HttpsURLConnection` does. Certpath validation always checks important extensions and expiration and optionally revocation, and in j7 up also for 'disabled' items like MD5 and RSA-512, in addition to signatures and anchor -- which it doesn't require be a root, although most are, ... – dave_thompson_085 Aug 03 '19 at 16:49
  • ... OpenSSL also added optional hostname checking more recently, 1.0.2 in 2015, which can be enabled in `s_client` by `-verify_host[name]` depending on version(!) – dave_thompson_085 Aug 03 '19 at 16:50