7 Replies Latest reply: May 10, 2012 4:44 PM by 846520 RSS

    certificate based authentication

    833384
      I have a client application that requires certificate based authentication.

      I could not find any instructions on how to set this up in the 11g manuals. So I reverted to the 5.2 manual (http://docs.oracle.com/cd/E19850-01/816-6698-10/ssl.html#18500), and followed some instructions found online.

      I have completed the setup, and the client is able to authenticate using his certificate, and I have verified this in the logs.
      [22/Mar/2012:13:13:33 -0500] conn=34347 op=-1 msgId=-1 - SSL 128-bit RC4; client CN=userid,OU=company,L=city,ST=state,C=US; issuer CN=issuing,DC=corp,DC=company,DC=lan
      [22/Mar/2012:13:13:33 -0500] conn=34347 op=-1 msgId=-1 - SSL client bound as uid=userid,ou=employees,o=company
      [22/Mar/2012:13:13:33 -0500] conn=34347 op=0 msgId=1 - BIND dn="" method=sasl version=3 mech=EXTERNAL

      When adding the usercertificate attribute to the ID I used the following LDIF:

      version: 1
      dn: uid=userid,ou=employees,o=company
      changetype: modify
      replace: userCertificate
      usercertificate: < file:///home/user/Certs/usercert.bin

      the file was a binary encoded certificate file.

      Here is the part that I don't understand when I do a search (or LDIF export) of the user object with the certificate it just returns a short base64 encoded string. when I decode this string, it is just the literal string of "< file:///home/user/Certs/usercert.bin".

      So it appears that the certificate has not been stored on the user object in binary, and yet the certificate authentication still works. The file mentioned, does not exist on the LDAP server (the cert was loaded from another server), so there is no way that it is reading the cert from the file.

      Anyone have any idea what is going on here? And why certificate auth works, when there appears to be not cert stored in LDAP?

      If by chance this is how it is all suppose to work, then how do I go about backing up the usercertificate attribute when I do my LDAP data backups?

      Thanks
      Brian
        • 1. Re: certificate based authentication
          807817
          There're actually 2 distincts parts in client certificate authentication.
          The first part is really standards (TLS,SSL v3) based: both client and server authenticate to each other as they'd if it was HTTPS for example.
          Then, ODSEE adds a second optional check (the 2nd part): it can make sure the certificate sent by the client is the same as the one stored
          in the LDAP entry for that client. That's why if you want to use that option, enabling it also requires to configure ODSEE so that it knows
          how and where to find the LDAP entry in its base, and where to find the attribute in the entry.
          So, in your case, I suppose you did not enable that second check, you only rely on the standards based SSL v3 client authentication protocol
          (which is not bad !)

          As a former Netscape and Sun PKI expert, I remember the second check was primarily intended in case of certificate renewal of the CA,
          to make sure clients would be using the right certificate after a while, preventing them to use a possibly still valid (from a time range point of view)
          certificate signed by the right CA but with an old CA key.

          Finally, I'm not sure you case use the certificate;binary as you try. The usual way is to store the base64 encoded PEM presentation of the certificate:
          first obtain your certificate in PEM format, and then, depending on the tools you use to import in the directory, you may have (or not) to encode
          the PEM value in base64 before assigning it to the certificate;binary attribute.
          • 2. Re: certificate based authentication
            833384
            Cyril,
            Thanks for the reply.

            I believe I am doing both types of certificate authentication, you are describing. My issue is that when I perform the steps to store the PEM formatted cert into the directory server, rather than storing a binary value of the cert, it appears to be storing the path to the file I attempted to import. The odd part is that I can still authenticate even after this is done.

            I tried to post as much info as I could before without posting any sensitive data, I'll try and expand on that below.

            Here is my documentation of the steps taken to configure the server and setup a user, for what I believe to be certificate based authentication, where the user is authenticated solely on the certificate that they provide (no password is sent).

            1. Server must be running SSL, all connections for Certificate Auth are done over SSL (just a note)
            2. From the DSCC
            ----a. Directory Servers Tab -> Servers Tab -> Click Server Name
            ----b. Security Tab -> General Tab
            ----c. In "Client Authentication" section, select:
            --------i. LDAP Settings: "Allow Certificate-Based Client Authentication"
            --------ii. This should be the default setting.
            3. On the directory server setup the /ldap/dsInst/alias/certmap.conf file:
            ----a. certmap default default
            ----default:DNComps
            ----default:FilterComps uid,cn
            4. restart the directory server
            5. Do the following to setup the user who will be connecting. On their unix account (or similar)
            ----a. Create a directory to hold the certDB
            --------i. mkdir certdb
            ----b. Create a CertDB
            --------i. /ldap/dsee7/bin/certutil -N -d certdb
            ------------1) Enter a password when prompted
            ----c. Import the CA cert
            --------i. /ldap/dsee7/bin/certutil -A -n "OurRootCA" -t "C,," -a -I ~/OurRootCA.cer -d certdb
            ----d. Create a cert request
            --------i. /ldap/dsee7/bin/certutil -R -s "cn=userid,ou=company,l=city,st=state,c=US" -a -g 2048 -d certdb
            ----e. Send the cert request to the PKI Team to generate a user cert
            ----f. Take the text of the generated cert & save it to a file
            ----g. Import the new cert into your certdb
            --------i. /ldap/dsee7/bin/certutil -A -n "certname" -t "u,," -a -i certfile.cer -d certdb
            ----h. Create a binary version of cert
            --------i. /ldap/dsee7/bin/certutil -L -n "certname" -d certdb -r > userid.bin
            ----i. Add the binary cert to the user's LDAP entry (version: 1 must be included - I read this in a doc somewhere, but it doesn't seem to matter)
            --------i. ldapmodify
            ------------1) ldapmodify -h host -D "cn=directory manager" -w password -ac
            ------------2)
            ------------version: 1
            ------------dn: uid=userid,ou=employees,o=company
            ------------sn: Service Account
            ------------givenName: userid
            ------------uid: userid
            ------------description: Service Account for LDAP
            ------------objectClass: top
            ------------objectClass: person
            ------------objectClass: organizationalPerson
            ------------objectClass: inetorgperson
            ------------cn: Service Account
            ------------userpassword: password
            ------------usercertificate: < file:///home/userid/Certs/userid.bin
            ------------nsLookThroughLimit: -1
            ------------nsSizeLimit: -1
            ------------nsTimeLimit: 180

            After doing this setup I am able to perform a search using the certificate:
            ldapsearch -h host -p 1636 -b "o=company" -N "certname" -Z -W CERTDBPASSWORD -P certdb/cert8.db "(uid=anotherID)"

            This search is successful, and I can see it logged, as having been a certificate based authentication:
            [23/Mar/2012:13:25:20 -0500] conn=44605 op=-1 msgId=-1 - fd=136 slot=136 LDAPS connection from x.x.x.x:53574 to x.x.x.x
            [23/Mar/2012:13:25:20 -0500] conn=44605 op=-1 msgId=-1 - SSL 128-bit RC4; client CN=userid,OU=company,L=city,ST=state,C=US; issuer CN=issuer,DC=corp,DC=company,DC=lan
            [23/Mar/2012:13:25:20 -0500] conn=44605 op=-1 msgId=-1 - SSL client bound as uid=userid,ou=employees,o=company
            [23/Mar/2012:13:25:20 -0500] conn=44605 op=0 msgId=1 - BIND dn="" method=sasl version=3 mech=EXTERNAL

            If I understand correctly that would be using the part 2 of your explanation as using the binary encoded PEM to authenticate the user. If I am not understanding that corretly please let me know.

            Now the part that I am really not getting is that the usercertificate that is stored on the ID is as below:
            dn: uid=userid,ou=employees,o=company
            usercertificate;binary:: PCBmaWxlOi8vL2hvbWUvdXNlcmlkL0NlcnRzL3VzZXJpZC5iaW4

            which decodes as: < file:///home/userid/Certs/userid.bin

            So I'm still unclear as to what is going on here, or what I've done wrong. Have I set this up incorrectly such that Part 2 as you described it is not what I have setup above? Or am I missunderstanding part 2 entirely?

            Thanks
            Brian

            Edited by: BrianS on Mar 23, 2012 12:14 PM
            Just adding ---- to keep my instruction steps indented.
            • 3. Re: certificate based authentication
              jmft2012
              I have not worked on ODSEE yet. Mainly I have worked on the OAM or OAS based for X.509 authentications (DoD CAC).
              But all should be relatively same when comes to the implementations.
              I believe the auth DID not validate the certs because in the configuration somewhere you did not explicitly set it for.
              As example in OAM, we have " Cert Validation Enabled" checked for enforcing the cert validation

              HTH

              Sean
              • 4. Re: certificate based authentication
                807817
                Hello Brian,
                2 things looks possibly wrong to me:

                1) The certificate presented by the client seems to have the following ubject DN: CN=userid,OU=company,L=city,ST=state,C=US and
                the certmap.conf file of ODSEE makes it interpret the certificate subject DN as "uid=userid,ou=employees,o=company". Is it really what
                you want ? If not, be sure to well understand the meaning of the configuration parameters in the certmap.conf file

                2) What don't you import the certificate in ASCII/PEM format ? : the PEM value should start by --------------BEGIN CERTIFICATE --------
                So you could just base64 that whole value and insert the result in the certificate;binary attribute as you would do with any other attribute
                with ldapmodify for example.
                • 5. Re: certificate based authentication
                  833384
                  Cyril,
                  1) Yes that is correct, my employee is located at: uid=userid,ou=employees,o=company
                  2) I didn't import the cert in PEM format, simply because the instructions I found for 5.2 specifically said to import the cert to binary format. I'll try using PEM format & see how that changes things.

                  My problem doesn't seem to be in making this work though (as it seems to work) my problem is more about, why does it work, considering that the stirng stored in the usercertificate attribute, is just the path to a file.
                  • 6. Re: certificate based authentication
                    807817
                    Again, if certificate verification is disabled (that is verifycert is off in the certmap.conf file) , the directory content doesn't matter.
                    • 7. Re: certificate based authentication
                      846520
                      Hi Brian,

                      Just my 2 cents

                      1) I agree with Cyril, if you don't have verifycert turned "on" in your certmap.conf file, the server won't bother matching the client certificate with the certificate store in the directory. Therefore it has no effect at all when you set up something like

                      usercertificate: < file:///home/userid/Certs/userid.bin


                      2) If you do really want to turn on verifycert, here is an example of certmap.conf

                      certmap example "CN=issuing,DC=corp,DC=company,DC=lan"
                      example:verifycert on
                      example:CmapLdapAttr description

                      As for setting usercertifcate:binary attribute, I'm not sure how it's done in version 5.x, but here is another way doing it

                      ldif -b "usercertificate:binary" < /home/user/Certs/usercert.bin
                      usercertificate:binary:: MIICUTCCAbqgAwIBAgIFAJNSsa8wDQYJKoZIhvcNAQEFBQAwajEL
                      MAkGA1UEBhMCRlIxDzANBgNVBAgTBkZyYW5jZTERMA8GA1UEBxMIR3Jlbm9ibGUxDzANBgNVBAoT
                      Bk9yYWNsZTENMAsGA1UECxMEVEVTVDEXMBUGA1UEAxMOQ0EgQ2VydGlmaWNhdGUwHhcNMTEwMTI0
                      MTEwMzQxWhcNMjEwMTI0MTEwMzQxWjBYMRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPy
                      LGQBGRYHZXhhbXBsZTEPMA0GA1UECxMGUGVvcGxlMRcwFQYKCZImiZPyLGQBARMHYWJhcm5lczCB
                      nzANBgkqhkiG9w0BAQEFAAOBjQAwgYk... (omitted)


                      ldapmodify -p <port> -D "cn=Directory manager" -w *****
                      dn: uid=userid,ou=employees,o=company
                      changetype: modify
                      replace: usercertificate:binary:
                      usercertificate:binary:: MIICUTCCAbqgAwIBAgIFAJNSsa8wDQYJKoZIhvcNAQEFBQAwajEL
                      MAkGA1UEBhMCRlIxDzANBgNVBAgTBkZyYW5jZTERMA8GA1UEBxMIR3Jlbm9ibGUxDzANBgNVBAoT
                      Bk9yYWNsZTENMAsGA1UECxMEVEVTVDEXMBUGA1UEAxMOQ0EgQ2VydGlmaWNhdGUwHhcNMTEwMTI0
                      MTEwMzQxWhcNMjEwMTI0MTEwMzQxWjBYMRMwEQYKCZImiZPyLGQBGRYDY29tMRcwFQYKCZImiZPy
                      LGQBGRYHZXhhbXBsZTEPMA0GA1UECxMGUGVvcGxlMRcwFQYKCZImiZPyLGQBARMHYWJhcm5lczCB
                      nzANBgkqhkiG9w0BAQEFAAOBjQAwgYk... (omitted)


                      See if it works for you. Cheers!