1 2 Previous Next 28 Replies Latest reply on Nov 30, 2018 7:24 AM by Brian Morris

    SSL Client Verification - Extract Key format

    Brian Morris

      I'm working on SSL Client Verification as shown here: https://docs.bmc.com/docs/display/DISCO113/Configuring+Web+authentication+settings#ConfiguringWebauthenticationsettings-SSL

       

      I'm not sure how to format the Extract Key so it matched the value that is being used in our LDAPS query (userPrincipalName).  The default value for Extract Key: emailAddress - was tried and doesn’t work. The username in userPrincipalName is in the format of 'a number @ a domain'. So for example 137801290@mail.foo.com.  LDAPS is working and is able to find the user and the user is already mapped to Discovery groups.  HTTPS is also working and enabled.

       

      From the documentation I see you can use subjectAltName and a sub value in this kind of format:

      subjectAltName—The entire extension name

      subjectAltName.emailAddress—Email address (as defined in RFC 822; for example, timothy_taylor@bmc.com "Taylor, Timothy")

       

      The value on the User's card that matches userPrincipalName is found under 'subjectAltName' -> 'otherName' and has an OID associated with a label called 'Principal Name'.  No combination of these values I've tried has allowed us to login and there are just no examples in the documentation other than "emailAddress". 

       

      This is what we see when we investigate the user's certificate:

       

      The standard OID for subjectAlternativeName is 2.5.29.17 and the value we want is under this OID.  (some documentation on it here and other places https://www.alvestrand.no/objectid/2.5.29.17.html)

       

      Extracting my user authentication certificate and viewing it using the command:

       

      certutil -dump -v mycert.cer

       

      Gives this relevent section:

       

      2.5.29.17:  Flags = 0, Length = 30

      Subject Alternative Name

           Other Name:

                Principal Name = 137801290@mail.foo.com

       

      AltName: 1 entries:

      AltName[0] CERT_ALT_NAME_OTHER_NAME: 1.3.6.1.4.1.xxx.xx.x.x Principal Name:

           CERT_RDN_UTF8_STRING, Length = 22 (22 Characters)

           "137801290@mail.foo.com"

      ...

       

      After this there is like a hex-code fingerprint that describes the data.  The value shown here: 137801290@mail.foo.com is the one we want, and this matches what LDAPS is finding with userPrincipalName.  As long as we can get there, like the doucmentation seems to indicate, this value should work.  The question is how do I format the Extract Key to get this value?  I've tried a variety of combinations of the subjectAltName, otherName, the oid, and used dots and colons and nothing works.

       

      What happens is ihe user is prompted to select a certificate and enter a pin when accessing Discovery but after selecting the user's certificate and entering the correct pin, Discovery just goes to a "Page cannot be displayed" page.

       

      Have run this with debug on and don't see much that's helpful (like what value, if any, has been tried or matched and what's being presented or the error message), but I see the certificate authority it's trying to validate against and it's valid but we end up with:

       

      ui.web.sso.webauth.sslclientcert: DEBUG: SSL_CLIENT_VERIFY found: NONE

      ui.web.sso.webauth.sslclientcert: DEBUG: SSL_CLIENT_VERIFY is not SUCCESS

       

      We've also worked through How to troubleshoot SSL client certificate issues? and KnowledgeArticle - BMC

       

      Given all this, I'm still not sure how to properly configure the Extract Key when it's not "emailAddress". 

        • 1. Re: SSL Client Verification - Extract Key format
          Andrew Waters

          As per the documentation, extract key must be a value in the distinguished name (i.e. the Subject in the client certificate). It does not support picking out other fields in the certificate.

          1 of 1 people found this helpful
          • 2. Re: SSL Client Verification - Extract Key format
            Brian Morris

            Hey Andrew,

             

            So I did see where the docs said that about DN, but it also has this section saying subjectAltName can be addressed, and maybe I'm not finding it clear:

            In 9.0 SP1 and later you can extract values from X.509 certificate extensions. The extension name subjectAltName is used as the extract key. The extension name is split into parts. The parts that you can extract are determined by the content of the certificate. For example you can refer to:

            • subjectAltName—The entire extension name
            • subjectAltName.emailAddress—Email address (as defined in RFC 822; for example, timothy_taylor@bmc.com "Taylor, Timothy")

             

            Since we have a valid SubjectAltName as shown in my post, are you saying it's impossible to address because it's not in the Subject object?  What I mean is, If I open this certificate in Windows I see an object called Subject that data like this:

             

            CN = MORRIS.BRIAN.5409891

            OU = CONTRACTOR

            OU = PKI

            OU = FOO

            O = BAR

            C = VALUE

             

            A bit further down in the same window, there is another object called Subject Alternative Name.  Is this not what the documentation is referencing in the snippet above?

             

            The Value in it looks like this:

             

            RFC822 Name=brian.morris.ctr@foo.com

            Other Name:

                 Principal Name=5409891@domain

             

            The Principal Name here would match the value found in userPrincipalName.

             

            Thanks for your help!

            1 of 1 people found this helpful
            • 3. Re: SSL Client Verification - Extract Key format
              Andrew Waters

              Sorry but I find your post really hard to read.

               

              You do not extract the 5409891@domain value, you can only extract an entry in the distinguished name not part of it. So you would get out Other Name.

              • 4. Re: SSL Client Verification - Extract Key format
                Brian Morris

                OK...

                 

                so "Other Name" appears to be what we want.  How do we make that the Extract Key in BMC Discovery?

                • 5. Re: SSL Client Verification - Extract Key format
                  Andrew Waters

                  You need the name of the field in the certificate - isn't it otherName?

                  • 6. Re: SSL Client Verification - Extract Key format
                    Brian Morris

                    Yes it should be according to the RFC, but an extract key of subjectAltName.otherName doesn't work.

                     

                    Using otherName also doesn't work.

                    • 7. Re: SSL Client Verification - Extract Key format
                      Andrew Waters

                      Difficult to tall from your post what name should be used.

                       

                      Doesn't work in what way? If you put the UI log level in debug what does it report in tw_appserver.log?

                      • 8. Re: SSL Client Verification - Extract Key format
                        Brian Morris

                        "Doesn't work" meaning after the user chooses their certificate from the browser popup and enters their pin, Discovery just goes to a "Page cannot be displayed" page.

                         

                        appserver Debug log shows:

                         

                        ui.web.sso.webauth.sslclientcert: DEBUG: SSL_CLIENT_VERIFY found: NONE

                        ui.web.sso.webauth.sslclientcert: DEBUG: SSL_CLIENT_VERIFY is not SUCCESS

                         

                        Oddly, if I view the certificate in Windows I can see the Subject Alternative Name.  If I upload it to the appliance and run openssl x509 -text -noout -in usercert.cer

                        I get:

                        ...

                        x509v3 Subject alternative Name:

                        othername:<unsupported>

                        ...

                         

                        I'm not sure if this really means anything though since apparently openssl used <unsupported> as a placeholder response since at least 2010 though since the datatype of "othername" was not controlled.  Source: ssl - OpenSSL always shows "unsupported" for all subjectAltName "otherName" UTF8 values - Server Fault  and https://archive.is/KZYqh

                        • 9. Re: SSL Client Verification - Extract Key format
                          Andrew Waters

                          So Apache is not even trying to verify the a client certificate. Are you sure the browser is presenting one?

                           

                          What version are you using? Presumably you have https enabled (as a documented requirement).

                          • 10. Re: SSL Client Verification - Extract Key format
                            Brian Morris

                            As in my initial description of the issue, HTTPS is enabled and working.  Version of Discovery is 11.3.0.3-751772.

                             

                            Well...  honestly - I'm sure that the certificates are loaded in the browser, I'm sure that the browser is asking for the user to choose a certificate when they  accesses the discovery web UI, and I'm sure that after a certificate is chosen, the user is prompted for the PIN associated with the certificate. 

                             

                            Unfortunately, I don't know for sure what's happening after that or how or what Discovery's Apache is doing with any of that.

                             

                            I believe Apache is configured to accept certificates.  On the appliance OS, running openssl s_client -connect localhost:443 is good, and I see that my client certificate is issued by a CA that is listed in "Acceptable client certificate CA names".

                             

                             

                            • 11. Re: SSL Client Verification - Extract Key format
                              Andrew Waters

                              I would expect the log to report either success or failure if apache tried to verify the certificate.

                               

                              Have you modified any of the Apache configuration?

                              2 of 2 people found this helpful
                              • 12. Re: SSL Client Verification - Extract Key format
                                Bernard Stern

                                You might want to look at this doc I just uploaded: https://communities.bmc.com/docs/DOC-111223.

                                2 of 2 people found this helpful
                                • 13. Re: SSL Client Verification - Extract Key format
                                  Brian Morris

                                  Andrew, the Apache config doesn't have anything that is custom, but it has had the tw_stig_control command applied.

                                  • 14. Re: SSL Client Verification - Extract Key format
                                    Brian Morris

                                    Thanks Bernard, that is a great article! I'm not sure how you're capturing the SSL Client Cert in the debug log though. I noticed that in my tw_appserver_log files the Client certs never seem to make it into the log, even though the browser is prompting for them and the appropriate pin.

                                     

                                    'SSL_CLIENT_CERT' : ''

                                    'SSL_CLIENT_VERIFY' : 'NONE'

                                    ......

                                    ui.web.sso.webauth.sslclientcert: DEBUG: SSL_CLIENT_VERIFY found: NONE

                                    ui.web.sso.webauth.sslclientcert: DEBUG: SSL_CLIENT_VERIFY is not SUCCESS

                                     

                                    When I look at my certificate, I don't have serialNumber (or anything really other than subjectAltName that looks usable, but SAN doesn't show in the output of openssl.)  The output looks like this, I've just modified your example with data from mine.  There is no values with a "/" in it, like you have in the Subject.  (Subject: C=ch, O=COMPANY, OU=Partner/serialNumber=12345, CN=bernhard stern)

                                     

                                    $ openssl x509 -in user-cert.cer -text

                                    Certificate:

                                        Data:

                                            Version: 3 (0x2)

                                            Serial Number: 74102 (0x3e96c)

                                        Signature Algorithm: sha256WithRSAEncryption

                                            Issuer: C=US, O=COMPANY, OU=XX, OU=XXX, OU=AUTHORITIES, CN=COMPANY CA

                                            Validity

                                                Not Before: Jun 26 05:31:48 2017 GMT

                                                Not After : Jun 26 06:01:48 2020 GMT

                                            Subject: C=US, O=COMPANY, OU=XX, OU=XXX, OU=CONTRACT, CN=MORRIS.BRIAN.5409891

                                            Subject Public Key Info:

                                                Public Key Algorithm: rsaEncryption

                                                    Public-Key: (2048 bit)

                                                    Modulus:

                                    00:de:18:be:00:82:41:95:66:86:4c:ba:8d:8e:cf:

                                                        ...

                                                        d1:af

                                                    Exponent: 65537 (0x10001)

                                            X509v3 extensions:

                                                X509v3 Key Usage: critical

                                                    Digital Signature

                                                X509v3 Extended Key Usage:

                                                    TLS Web Client Authentication, Microsoft Smartcardlogin

                                                X509v3 Certificate Policies:

                                                    Policy: 1.3.6.1.4.1.4147.30.1.1.24.1

                                                X509v3 Subject Alternative Name:

                                                    othername:<unsupported>

                                                X509v3 CRL Distribution Points:

                                                     Full Name:

                                                      URI:http://crl.somedomain.com/internalca.crl

                                                 X509v3 Authority Key Identifier:

                                    keyid:E4:2E:80:CA:52:07:A9:64:FA:20:86:06:31:D2:AA:A4:52:AB:D0:23

                                                 X509v3 Subject Key Identifier:

                                    B5:DA:4B:26:7B:EC:19:B2:C5:5A:BF:78:E7:AD:98:8A:9A:90:6D:BD

                                                X509v3 Basic Constraints:

                                                    CA:FALSE

                                                1.2.840.113533.7.65.0:

                                                    0

                                    ..V8.1....

                                        Signature Algorithm: sha1WithRSAEncryption

                                    8d:95:d9:da:25:44:fe:51:6d:20:05:f3:68:92:36:4e:b0:6d:

                                             ...

                                             b5:f3:c0:cd

                                    -----BEGIN CERTIFICATE-----

                                    MIIFXDCCBESgAwIBAgIEVA2MljANBgkqhkiG9w0BAQUFADBMMQswCQYDVQQGEwJj

                                    ...

                                    t0OSqSWQYp6poleHyH/eSXogYonvWER4NlEBBrXzwM0=

                                    -----END CERTIFICATE-----

                                    $

                                    1 2 Previous Next