MQ

 View Only
  • 1.  SSLCERTI

    IBM Champion
    Posted Wed October 19, 2022 07:29 PM
    A. Is there any valid scenario to use SSLCERTI on your CHLAUTH rules if your queue manager's trust store (keystore) contains only a single Certificate Authority's root?

    B. If your queue manager's trust store (keystore) contains multiple root certs, and you want inbound ChannelA to only run with certs issued by Cert Authority A, and inbound ChannelB to only run with certs issued by Cert Authority B, is this where you use SSLCERTI is to pass/fail the direct Intermediate Signer cert?
    If true, is this based on the assumption that Cert Authority A and Cert Authority B will never both issue an Intermediate signer cert that has the same DN?
    If true, why is it safe to assume that? I don't think Cert Authorities check with each other to ensure no overlap on the DN of their Intermediates, or do they?


    ------------------------------
    Peter Potkay
    ------------------------------


  • 2.  RE: SSLCERTI

    IBM Champion
    Posted Thu October 20, 2022 02:31 AM
    They may not. But usually it is quite obvious:
    Digicert root CA issues Digicert TLS ...SHA256 CA and it is the same for other Certificate Authorities.

    It can happen that the intermediate has a different name when the Certificate Authority has been acquired by the root CA.

    Hope this explains it.

    ------------------------------
    Francois Brandelik
    ------------------------------



  • 3.  RE: SSLCERTI

    Posted Thu October 20, 2022 03:33 AM
    Hi Peter,

    A. If you only have one trusted root CA and your certificates are all issued by that CA (no intermediates) then SSLCERTI wouldn't add anything over the standard TLS trust chain. If you have one root CA but more than one intermediate CA then you could use it to distinguish between the two intermediate CAs.

    B. If i remember correctly, SSLCERTI runs off the issuing certificate for the subject certificate not the full chain. So in the case you describe here, whereby two different RootCAs issue intermediates with the same name and then those issue certificates,  you may not be able to distinguish the different issuers by name alone. However, the serial number can be included in the distinguished name and filtered on so assuming that number would be different it may be your option here to work out which is from which Root CA.

    ------------------------------
    Rob Parker
    Security Architect, IBM MQ Distributed
    IBM UK Ltd
    ------------------------------



  • 4.  RE: SSLCERTI

    IBM Champion
    Posted Thu October 20, 2022 10:53 AM
    A. Got it. Not sure why you would allow some but not all intermediate signers from a particular Cert Authority, but if the requirement presented itself I see how SSLCERTI might be useful even when the trust store has a single root CA cert.

    B. Yes, SSLCERTI is only looking at the immediate issuer's cert which may itself be 0 or more intermediates away from the actual root CA cert.. If you can predict what that immediate Intermediate cert will be AND assume 2 CAs will never issue intermediates with the same DN, I can see how SSLCERTI is useful. But as CAs renew leaf certs its not uncommon that the Immediate issuer cert will change during the renewal requiring an update to the SSLCERTI. Hopefully proactively if you know that's the case, I fear reactively in most cases.

    Re: 2 CAs creating Intermediates with the same DN, I assume they would never do it by design. I'm just overdoing it with the what-ifs I guess. What if they accidentally have the same DN values? <<rhetorical question

    Before I finished reading and playing with SSLCERTI I assumed it would allow checking and then pass/failing all the way up at the root level. The "Issuer" in my initial reaction was the Certificate Authority itself, not one of its Intermediate certs.

    I don't have the requirement right now, this is just more thinking out loud - I imagine in some cases it would be useful to have a version of SSLCERTI that can further check against the root or maybe (?) better yet, the ability to have individual channels reference individual trust stores.  

    I do understand that we can pass/fail down to the individual serial number of a SSL peer's cert. A lot of work at scale.


    ------------------------------
    Peter Potkay
    ------------------------------



  • 5.  RE: SSLCERTI

    Posted Thu October 20, 2022 01:03 PM
    You might also find this blog post on TLS authentication by serialnumber and sslcerti helpful.

    https://community.ibm.com/community/user/integration/blogs/tim-zielke1/2020/04/25/using-serialnumber-with-tls-authentication-in-ibm

    There are different use cases for sslcerti, but I personally use it to document the issuer for a unique certificate (unique means validated by serialnumber and for a specific issuer) that I am going to allow with a CHLAUTH rule. When you get down to this level of uniqueness for cert validation, it become very difficult if not impossible for an imposter to spoof the cert you are accepting. If your remote ends are able to swap in new certs and connect to your queue manager without you knowing about it or requiring you to make adjustments to your CHLAUTH rules, that does pose the question of how viable is it for an imposter to do the same?

    ------------------------------
    Tim Zielke
    ------------------------------



  • 6.  RE: SSLCERTI

    IBM Champion
    Posted Fri October 21, 2022 05:06 PM

    Tim wrote: "If your remote ends are able to swap in new certs and connect to your queue manager without you knowing about it or requiring you to make adjustments to your CHLAUTH rules, that does pose the question of how viable is it for an imposter to do the same?"

    The imposter would have to get the one Certificate Authority in my trust store to issue a replacement certificate whose DN is exactly what I have the SSLPEER field. If the CA will do that for the imposter we got bigger problems.

    If you do filter on the Serial Number, how do you get that Serial Number in the first place?
    A. If you rely on the partner supplying it out of band ahead of time using a trust worthy communication method, that works for low # of partners who you can depend on to work with you or if you control both ends. It can be very precise and very "secure". It is a viable option in certain use cases. But generally it does not scale.
    B. if you rely on seeing it when the partner makes the TLS connection with the new cert I don't understand how/why you trust that incoming connection as being legit - how do we know that is not the imposter?

    When calling your bank's website, how do you trust that is not an imposter without having set up your browser to only accept a specific cert's serial number?



    ------------------------------
    Peter Potkay
    ------------------------------



  • 7.  RE: SSLCERTI

    Posted Sat October 22, 2022 09:41 AM
    If you are validating the entire DN, then I agree a CA should have protection from an imposter attempting to get a certificate request signed by the CA with the same DN as your cert. If an MQ admin is not checking the DN, checking only portions of it, using wildcard checks, etc., that is where you definitely need to be aware of this exposure. I also understand the concern of scale when adding the serial number check, and you would probably need an approach like A to do this, although it is definitely feasible to automate this via programming (i.e. a TLS channel PUTs a specific message to a queue that includes the new cert and triggers a program that creates the CHLUATH rule for the new cert with the serialnumber/issuer check). If you automate this via programming, you would have to first do A to trust the cert by serialnumber, and then you could trust future automated requests to add a new cert as long as it is coming from the channel with a cert with the serialnumber that you set up to trust. 

    If you are not checking the serial number of the cert, you do need to be aware that you are relying on your CA to prevent an imposter from getting a certificate that can pass your other checks of the cert. However, I do understand your point that CA's should be set up to provide this protection. Your example of how you trust your bank's website is a fine example of this. For me, I like to do the TLS channel authentication to the finest level of security, so that would be checking the serialnumber/issuer of the cert.

    ------------------------------
    Tim Zielke
    ------------------------------