IoPT Consulting, LLC 2 June 2015

Transcription

1 NY/NJ IBM MQ & Application Integration User Group 1

2 NY/NJ IBM MQ & Application Integration User Group 2

3 NY/NJ IBM MQ & Application Integration User Group 3

4 NY/NJ IBM MQ & Application Integration User Group 4

5 The first step in creating a certificate is to generate a public/private key pair and the attributes to which the certificate will attest i.e. the subject s name, organization, etc. If the certificate is to be self signed, the private key just generated is then used to sign the certificate, binding the identity to the keys in the process. Connection partners needing to trust the certificate must have a copy of that certificate s public key which has been (hopefully) securely delivered or is reliably verified. If the certificate is to be CA signed, a Certificate Signing Request (CSR) is generated and submitted to a CA for signing. The signed public certificate is returned and received into the keystore. In order to validate the signed certificate, the CA s root cert must be in the keystore before the signed personal cert can be received. NY/NJ IBM MQ & Application Integration User Group 5

6 A personal certificate contains all the elements of the public certificate, as well as the private key. NY/NJ IBM MQ & Application Integration User Group 6

7 In this implementation, QMGRA has a personal certificate and the root and any signer certificates that signed it. Neither QMGRB nor the client have their own certificate but they must have the CA Root and any signer certificates in their keystore in order to validate the certificate passed by QMGRA. Note that a successful TLS handshake has not authenticated QMGRA. It merely validates that QMGRA s certificate has not expired, and was signed by a CA root certificate that is known, trusted and also unexpired. Optionally, the revocation status of QMGRA s certificate can be checked. Actually authenticating QMGRA requires a CHLAUTH rule or exit to verify that the Distinguished Name of the certificate corresponds to the expected value for QMGRA. This occurs after the TLS handshake completes. NY/NJ IBM MQ & Application Integration User Group 7

8 In this implementation, all nodes have their own personal certificate and the root and any signer certificates that signed it. Note that a successful TLS handshake has not authenticated QMGRA. It merely validates that QMGRA s certificate has not expired, and was signed by a CA root certificate that is known, trusted and also unexpired. Optionally, the revocation status of QMGRA s certificate can be checked. Actually authenticating QMGRA requires a CHLAUTH rule or exit to verify that the Distinguished Name of the certificate corresponds to the expected value for QMGRA. This occurs after the TLS handshake completes. NY/NJ IBM MQ & Application Integration User Group 8

9 Self Signed A self signed certificate is one in which the public key, policy attributes and identity attributes have been signed by the private key corresponding to the public key bound by the signature. The certificate was literally used to sign itself. Self signed does NOT mean signed by our internal CA or any other interpretation in which one certificate is signed by another. NY/NJ IBM MQ & Application Integration User Group 9

10 Root certificate A root cert is a self signed certificate used to sign other certificates. At the top of every CA signer chain, the root certificate is self signed. You can verify this by inspecting the Subject and Issuer fields. The Distinguished Name, Fingerprint and other attributes will be identical. At a robust and reliable certificate authority, root certificates are stored offline in vaults. Typically, dual knowledge access procedures are enforced and any access is audited. Strict security hygiene, especially with respect to the root certificates, provides the basis for trusting the CA. NY/NJ IBM MQ & Application Integration User Group 10

11 Executing a certificate signing request: The user generates a key pair. The public key and attributes of the key pair are bound to a certificate signing request. The CA modifies the identity attributes as per policy and certificate type and attaches their public certificate. The CA then signs the package which produces a public certificate. The user receives the public certificate into their KDB which binds to the private key to form a personal certificate. NY/NJ IBM MQ & Application Integration User Group 11

12 Validating a certificate involves walking back up the signer chain. 1. The certificate presented is checked for validity. 2. The issuer certificate specified by the public certificate is validated. This is probably an intermediate signer certificate. 3. Each certificate in turn is checked for validation before moving up the chain to the parent issuer until reaching a root certificate which MUST be in the trust store. 4. If all certificates in the chain are valid and the root cert is in the trust store, the validation succeeds. NY/NJ IBM MQ & Application Integration User Group 12

13 Keystores and trust stores Keystores are containers for keys and certificates. In addition to merely holding these artifacts, the keystore is encrypted which provides an integrity check and some degree of privacy in the format. Queue managers use a single file, the KDB, to hold keys and certificates. Generally, keystores are generated and populated where they will be used. Pubic/Private keys were invented in part to solve the problem of key distribution. Moving the private keys around nullifies much of the benefit of public/private keys. A trust store is simply a keystore file that contains only trusted certificates. Since it contains no private keys, the trust store can be deployed through normal change control procedures (assuming those have some rigor). For example, in a web farm identical trust stores can be deployed at all instances along with other configuration assets. NY/NJ IBM MQ & Application Integration User Group 13

14 Each certificate contains many attributes. Once signed, the attributes cannot be changed without invalidating the certificate. It is this designed brittleness that provides the assurance that the representations clamed by the certificate are valid. NY/NJ IBM MQ & Application Integration User Group 14

15 The certificate actually contains two sets of attributes. Subject attributes pertain to the certificate holder. Issuer attributes pertain to the certificate signer the CA in this case. Since neither the Subject nor Issuer attributes can be altered, validating the certificate chain involves first validating the certificate itself, cryptographically and on things like the validity date, then performing the same process on the certificate names as the issuer. If the certificate was properly provisioned, the issuer certificate will be available in the KDB or trust store. NY/NJ IBM MQ & Application Integration User Group 15

16 These terms, their meanings, and the policies associated with each type, are all defined by the CA/Broswer forum. Please see: NY/NJ IBM MQ & Application Integration User Group 16

17 The standard certificate usually has the domain name as the Common Name and the www subdomain in the Subject Alternative Name. This is the most restrictive certificate, therefore is the cheapest, and therefore minimizes certain types of risk. A wildcard certificate is good for any subdomain of the primary domain. This certificate costs a bit more but allows you to add a new subdomain at any time. There s a bit of risk inherent in pre provisioning all possible names as being authenticated. A UCC certificate can represent up to 99 different domains in the Subject Alternative Name field. This is a special purpose certificate that is helpful for network edge devices like Content Distribution Network servers and caching servers that host many domains. The risk is that for purposes of authentication all named sites are equivalent. NY/NJ IBM MQ & Application Integration User Group 17

18 Each level of certification requires more validation, takes longer to issue, and costs more to purchase. The Domain Validated Certificate is usually pretty quick since the validation is so minor that it can be automated. One validation method is when the CA sends an to the address listed in the DNS registry entry for the requesting domain. Another method is that the CA supplies a file or some metadata which the requestor then posts to the web site of the requesting domain to prove they have access. Because of the minimal validation, these certificates do not result in a green padlock in the browser s address bar, but they do validate properly. Notes continued on next slide. NY/NJ IBM MQ & Application Integration User Group 18

19 The Organization Validated Certificate requires the CA to look up the registering company s legal entity. To obtain one requires decloaking the domains DNS entry if it is protected. The DNS entry must them match exactly the address and other details provided in the Certificate Signing Request. Because of the additional level of validation, these certificates are the minimum preferred for ecommerce web sites. These certs produce the padlock icon. The Extended Validation certificate undergoes much more thorough checking of the requestor. The current EV verification guidelines list 14 different verifications. The subscriber must also sign a contract binding them to uphold their obligations under the EV certificate policies. The chart from for consumers/ provides a comparison of the differences in functionality for each type of certificate. NY/NJ IBM MQ & Application Integration User Group 19

20 In previous MQ tutorials, the use of multiple OU fields was recommended to allow the administrator to embed values that the SSLPEER, CHLAUTH rule or exit could filter on. For example, many shops currently put the staging level (PROD, QA, etc.), the certificate type (QMGR, APP or ADMIN, USER), the cluster name, etc. They then set up an SSLPEER, CHLAUTH rule or exit to filter out the certificates they do not want. For example, a single rule that accepts all certs with OU=USER on a given SVRCONN is a lot easier than defining a dedicated channel for each user and a lot safer than not distinguishing between ordinary users, administrators, and applications. Because of restrictions the CAB Forum implemented a few years back, the MQ administrator must now choose between using a commercial CA, versus using an internal CA, or including these useful attributes in self signed certs. NY/NJ IBM MQ & Application Integration User Group 20

21 The CAB Forum rules require all information in the Subject attributes to have been validated. Whether a CA considers the OU fields (or more than one of them) to have been validated is up to the individual CA. In general though, the trend has been to disallow multiple OUs so even a CA that currently honors them may not do so in the future. NY/NJ IBM MQ & Application Integration User Group 21

22 As of a few years ago, the CAB forum requires all Common Name fields to be externally resolvable domain names. That means CN=MYQMGR now needs to be CN=MYQMGR.MYDOMAIN.COM at a minimum. Since we lack the OU fields, it is possible to fake them using subdomains. For example, CN=MYQMGR.MQ.MYDOMAIN.COM helps to ensure that your requested name does not collide with some other server or app. Taking it a step further, CN=MYQMGR.CLUSTERNAME.MQ.PROD.MYDOMAIN.COM is perfectly valid as a domain name and might even be honored by your CA of choice. If this is important to you, verify that your prospective CA will honor the names you want to use before signing up for a bulk contract! NY/NJ IBM MQ & Application Integration User Group 22

23 The DV certificate is all you need. The OV certificate adds no value for an MQ deployment. The EV certificate is a lot more money, but *may* allow you to specify one or more OU fields. Wildcard certs are not helpful at all. With MQ s authentication model, each certificate uniquely represents a single entity. There are no MQ architectures in which sharing certificates is a recommended practice. The UCC cert may be an alternative if you want to stash some info in the SAN that you would otherwise put in the OU. HOWEVER, the CA will most likely require these to be unique in the namespace. So do not put your CLUSTERNAME.MYDOMAIN.COM in the SAN because the CA will not allow a collision on that name. On the other hand, a unique ID such as the QMgr, user ID or app ID would work. NY/NJ IBM MQ & Application Integration User Group 23

24 The steps to deploying a certificate at a QMgr are provided in the slide. These are roughly the same regardless of whether you are generating a cert for MQ, for a client app, for Explorer, or whatever. Even platforms such as iseries and z/os which have specialized key management follow the same basic procedure. NY/NJ IBM MQ & Application Integration User Group 24

25 The first step in creating a certificate is to generate a public/private key pair and the attributes to which the certificate will attest i.e. the subject s name, organization, etc. If the certificate is to be self signed, the private key just generated is then used to sign the certificate, binding the identity to the keys in the process. Connection partners needing to trust the certificate must have a copy of that certificate s public key which has been (hopefully) securely delivered or is reliably verified. If the certificate is to be CA signed, a Certificate Signing Request (CSR) is generated and submitted to a CA for signing. The signed public certificate is returned and received into the keystore. In order to validate the signed certificate, the CA s root cert must be in the keystore before the signed personal cert can be received. NY/NJ IBM MQ & Application Integration User Group 25

26 The KDB or trust store contains all of the CA certificates that are trusted to sign authorized certificates for connections to the queue manager. The latest GSKit does not populate the keystore or KDB when it creates that file. It is up to the administrator to add the specific signer certificates that are authorized. Although IBM provides certificates from several CAs, the best approach is to generate the KDB or keystore empty, and then load up the CA bundle that is provided with your signed certificate. NY/NJ IBM MQ & Application Integration User Group 26

27 In the web world, such as when you connect to your bank, it is the server that we wish to authenticate during the connection. The user will authenticate later with an ID and password or other means after the TLS connection is built. In the MQ world, you as the administrator of the QMgr often need to authenticate the client during the connection request. The QMgr must authenticate itself to the client first, and what you need is for the second step to occur in which the client authenticates to the server with its certificate. This is known as mutual authentication. Though this may be your final objective, resist the urge to configure mutual auth with the initial configuration. This drastically complicates debugging and diagnosis if anything goes wrong. NY/NJ IBM MQ & Application Integration User Group 27

28 1. Download MS0P from 2. Events and the MS0P will help with diagnostics if anything goes wrong. 3. This ensures that the underlying connectivity and routing is good. 4. Load up the CA signer chain certs in both the server and client. Load the server s personal cert. Make sure that the client DOES NOT have a personal cert. If it has one it will send it, even though SSLCAUTH(OPTIONAL) is set. Perform a RESET SECURITY TYPE(SSL) on the QMgr or reboot it to make sure it finds the personal cert, then change SSLCIPH on the server and client channels. 5. This involves adding the client s personal cert and restarting it. Set SSLCAUTH(REQUIRED). 6. This is how you narrow down the population of acceptable certificates from anything the CA ever signed to the specific Distinguished Name(s) you want to allow. NY/NJ IBM MQ & Application Integration User Group 28

29 NY/NJ IBM MQ & Application Integration User Group 29

30 IoPT Consulting, LLC NY/NJ IBM MQ & Application Integration User Group 2 June