Hi Glen,
> Commercial CAs vary in their enforcement of these fields.
No, actually, they don't. They are identical because the CA/Browser Forum (aka CAB forum and the industry body that standardizes all the services offered by commercial CAs) enforces extremely strict standards. What any reputable commercial CA allows in the DN is determined by certificate type and depends on how much verification the customer pays for. Any CA that deviates from these rules is widely blacklisted and one can say with high confidence that no company using MQ would purchase certs from a blacklisted CA, therefore it would be more accurate to say there is zero deviation in DN naming among commercial CAs. Occasionally when the standards change there is variation of DN fields between newer and older certs but that's a variation over time and not across CAs.
If you pay for a Domain Validated (DV) certificate, they validate that the requestor controls the domain sufficiently to place records into its DNS, or to post a file with a particular URL inside the domain, or can respond to the email address registered in the DNS entry. Since that's the only thing validated, that's the only thing allowed in the DN.
Obtaining Organizational Validated (OV) certificates requires the requestor to prove everything from the DV and then also the organization exists, is not sanctioned, and that he or she is an authorized agent of it. The fields in the DN such as address and name are taken from official filings of the organization and must match exactly. The email address must be proved to exist and respond to validation emails addressed to it.
To get an EV certificate requires the CA to verify everything from the OV and also things like the company's bank account. Since everything in the DN must have been validated, getting an OU into the DN requires the CA to validate not just the approval of the requesting company's authorized agent but also that the OU either does not represent a trademarked name or natural name, unless the requesting company can prove they own the rights to the name requested. So, for example, a reputable CA would prevent me from including OU=IBM in my certificate even though I may have outsourced a department to IBM and think that's a good way to differentiate their certs from those of other departments.
Any CA that wants to be loaded into browsers must adhere to CAB Forum policies and any browser that wants to be trusted for inclusion in an OS or pre-loaded on a device must as well. (Hence the 'CA' and 'Browser' in the name 'CA/Browser Forum'.) In addition to the rules for types of certificates, there are specific requirements as to physical controls, security protocols, certificate lifecycle management, namespace management, and more. You can read more about all this at:
https://cabforum.org> Note that some software, web browsers specifically, check web site certificate CN fields against the user requested URL. In this case, the web server DOES NOT check the client certificate from your computer (hence the need for SSLCAUTH) in the MQ world.
A lot of software, actually. Along with basic and cert chain validation, matching the URL to the CN is a primary control for clients accessing servers using SSL or TLS. If this were not true it would be really easy to MITM LDAP, VPN connections, IPSec, DNSSec, etc.
The comparison is also a bit over simplified in that the web server doesn't check the client cert in the browser because the human running the browser authenticates by ID and password, smart card, or other means when client authentication is required. It has always been the case that mutual auth using SSL or TLS was supported. Like MQ, there are configurations that determine whether the client must send a cert or not, and also like web servers fail to accept the client connection if the client's cert doesn't authenticate. The options for server-only or mutual-auth on web servers and MQ using SSL or TLS are *the* *same*. If you want to enforce client-authenticated TLS sessions that has to be enabled in either case and SSLCAUTH is merely the MQ syntax for that.
The URL -matching problem in the MQ world is that the QMgr name and the DNS name of the server hosting it almost never match. This is especially true when there are multiple QMgrs on a single host, or more recently when MIQM is used. The result is that automated derivation of the correct CN for a QMgr is impossible so the MQ Admin has to configure that using SSLPEER and the admin needs to consider that on both sides of the handshake.
So when the client wants to authenticate the MQ server, SSLPEER in the CLNTCONN or MQCONNX must specify the DN fields required to make sure the MQ server is the right one. Since the MQ server MUST present a cert in a TLS session, this requirement exists virtually all of the time. (The exception is when the MQ server presents a self-signed cert and the client trusts ONLY that cert and no other roots, but that's rare.) Note that in TLS terms, "client" is the thing that initiates the connection so for MQ client can be another QMgr, in which case set SSLPEER on the outbound SDR, SVR, CLUSSDR, or RQSTR.
If the server wants to authenticate the client during the TLS handshake (and we hope it does), then SSLCAUTH(REQUIRED) on the SVRCONN, CLUSRCVR, RCVR, or SVR forces this part of the protocol to occur. Again, SSLPEER must be used to match the DN fields to the authorized cert(s).
Any time that more than one root cert is trusted, the SSLCERTI field can be used to bind the specified SSLPEER to a particular signer cert. For example, if the QMgr trusts root certs from GoDaddy and from IoPT Consulting (me) and I know it has a B2B connection with ACME, I can issue a cert with a DN that matches the ACME cert. If the QMgr specifies SSLCERTI my spoofing will fail. If not, I'm in.
> What the certificate really represents is the following:
1. A key
2. One or more identifiers
3. Policies
4. One or more trust anchors
5. Authoritative revocation responder address(es)
…all of which are bound together cryptographically. Because they cannot be altered once bound they can be validated with some assurance. So when we say "know your technology" it comes down to understanding which parts of the protocol validate which of these components and from a business perspective which of those validations is required, considered from both sides of the handshake.
We check the key in all cases. We authenticate the trust anchor in all cases. That's walking the signer chain to a root cert in the trust store or KDB.
We get basic validation in all cases. That's things like cert integrity, validity window, and usage policies. The problem here is how few people understand the usage policies. For example, if I give you a self-signed cert made with an older version of GSKit, it comes with policy of CA=TRUE which means I can spoof any cert your QMgr trusts. Newer versions of GSKit issue self-signed certs with CA=FALSE by default. A root cert is a self-signed cert with CA=TRUE but its policies prevent using it as a personal cert. If I give you a root from my company's internal CA you probably want to make sure it can't be used by my QMgr or MQ client as a personal cert. The MQ Admin needs to understand the policies bound into a cert and validate these against the business requirement. (In most practice the policies that differentiate between personal and root/signer certs are the ones we absolutely MUST enforce when adding a cert to the KDB.)
We omit the revocation check in MQ or perform it lazily in almost all cases. This needs to be validated against the business requirement a lot more than it is.
We need to match the remaining attributes to business requirements in pretty much all cases. As either a client or server (in the TLS sense of those terms) if we want to authenticate the thing on the other side we need something to specify the DN of authorized cert or certs. This is a combination of SSLPEER, SSLCERTI, and on the QMgr only, SSLPEERMAP. We always perform some authentication on the server but if we need to know the thing connecting is valid we use SSLCAUTH.
Note that we can omit SSLCAUTH and the cert on the client side in cases where CONNAUTH is used. In that scenario we are still authenticating the client, just using ID and password instead of certificates. It is still considered mutual auth even though SSLCAUTH(OPTIONAL) is set.
(Of course, not using CONNAUTH is a better policy until all components involved have been upgraded to an MQ version that performs CONNAUTH/CHLAUTH securely and consistently, which is a version of MQ that IBM has yet to provide, but that's a discussion for another thread.)
> In this case, there is no individual identify related to the certificate
Did you mean "identifier" here? A single cert used across multiple servers can have a single identifier (the CN) or the CN plus identifiers in the SAN extension. In either case, the cert resolves to a single entity.
For example, a cert used for a Content Distribution Network (CDN) like Akamai will have the CDN name in the CN and the names of all the other domains it serves in the SAN field. The entity represented by the cert is the union of all domains the cert is valid for - possibly a score of identities - and a single security policy representing the one entity applies across all identities. Since the same CDN can serve content for a top-tier web site and a malicious web site under the same cert this policy rather sucks. It adds as much risk as it adds speed and is one of the reasons people claim the CA trust system is broken today. Multiple identifiers, one entity, multiple identities.
In the case where a single cert with only a CN and no SAN entries is used across multiple servers it represents a single entity that resolves to a single identity. Note that this is only possible when a VIP or load balancer presents a single DNS name for all of the servers and the client is doing the normal URL-to-CN matching validation. In this way, the fact of multiple back-end servers doesn't splinter the entity into multiple identities. One identifier, one entity, one identity.
Sorry for the long email but there's no short way to describe some of this stuff and not be ambiguous, and when it comes to security ambiguity leads to exposure.
Kind regards,
-- T.Rob
T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB (8762) Voice/Text
https://ioptconsulting.com https://ioptconsulting.com https://twitter.com/deepqueue https://twitter.com/deepqueuecid:
image001.png@01D3A4AD.C76FB280From: Glen Brumbaugh, 98285 [
mailto:wsmqfam-ws@lists.imwuc.org]Sent: Tuesday, April 03, 2018 20:04 PM
To:
WSMQFam-ws@lists.imwuc.orgSubject: [WSMQFam-ws] - x.509 Certificates versus Identity
There've been some discussions around security that relate to x.509 (SSL/TLS) certificates as a form of identity. I wanted to put this concept into context. First of all, the origination of the x.509 standard dates back to the late 1980's, so this is not at all a new mechanism. These certificate were designed to be able to hold a variety of information. Email addresses, DNS names, and IP addresses are commonly used.
However, the Distinguished Name (DN) field is where the "identity" is normally contained. The DN has a number of sub-fields: Common Name (CN), Organization (O), Organizational Unit (OU), Location (L), State (ST), Country (C), etc. Most, if not all, of these fields are optional within the formal x.509 specification and can be whatever is requested in the Certificate Signing Request (CSR) and supported by the Certificate Authority (CA). Commercial CAs vary in their enforcement of these fields. Internal (to your organization) can implement whatever controls they wish.
Consider a certificate with the following Distinguished Name (DN):
*CN: I hold this certificate.
*O: Who cares.
*OU: I really don't care.
*C: Somewhere
What identify does this x.509 Certificate assert? The answer, of course, is none. Even if these fields were populated, they are not looked at by MQ unless the SSLPEER parameter is invoked to filter out certificates not meeting the specified values. What the certificate really represents is the following:
*I hold a certificate issued by someone you trust.
*You therefore trust what the certificate tells you about me. It's up to the certificate requestor, the CA, and the MQ SSLPEER parameter to determine the value of the certificate contents.
Note that some software, web browsers specifically, check web site certificate CN fields against the user requested URL. In this case, the web server DOES NOT check the client certificate from your computer (hence the need for SSLCAUTH) in the MQ world.
I have seen environments where a single certificate is deployed to multiple servers. In this case, there is no individual identify related to the certificate, only a membership in a trusted group of holders of that certificate.
Bottom line, certificates can be used to establish identity, but the possession of certificate does not ensure identify unless:
1.The certificate contains the necessary fields
2.The certificate fields are checked.
Bottom line, know your technology: The Good, The Bad, and the Ugly
http://www.imdb.com/title/tt0060196 .
Regards,
Glen Brumbaugh
-----End Original Message-----