Difference between revisions of "Client certificate authentication ipa"

From Asenjo
Jump to: navigation, search
m
m
Line 68: Line 68:
 
<pre>
 
<pre>
 
$ ipa user-show user10
 
$ ipa user-show user10
ipa: ERROR: Could not create log_dir u'/home/admin/.ipa/log'
 
 
   User login: user10
 
   User login: user10
 
   First name: ipa
 
   First name: ipa
Line 106: Line 105:
 
</pre>
 
</pre>
 
which will give you all the certificate output on screen.
 
which will give you all the certificate output on screen.
 +
 +
== map certificate to user account ==
 +
Canonical info:
 +
 +
http://directory.fedoraproject.org/docs/389ds/howto/howto-certmapping.html
 +
 +
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_SSL-Using_Certificate_Based_Authentication.html
 +
 +
* verify /etc/dirsrv/slapd-INSTANCE-NAME/certmap.conf looks like this:
 +
</pre>
 +
certmap default        default
 +
#default:DNComps
 +
#default:FilterComps    e, uid
 +
#default:verifycert    on
 +
#default:CmapLdapAttr  certSubjectDN
 +
#default:library        <path_to_shared_lib_or_dll>
 +
#default:InitFn        <Init function's name>
 +
default:DNComps
 +
default:FilterComps    uid
 +
certmap ipaca          CN=Certificate Authority,O=SUB.DOMAIN.TLD
 +
ipaca:CmapLdapAttr      seeAlso
 +
ipaca:verifycert        on
 +
</pre>
 +
 +
As you see, there is a 'default' mapping and an 'ipaca' mapping.
 +
 +
WARNING!!!
 +
 +
Do not modify anything of the ipaca mapping unless you know what you are doing. You risk messing up your pki tomcat service and plenty of things will stop working.
 +
 +
WARNING!!!
 +
 +
As you see, the ipaca mapping is your ipa server PKI. It has a CmapLdapAttr mapping attribute to the ldap object attribute seeAlso.
 +
 +
When I searched a test ipa environment, the only account with a seeAlso attribute was the "DN: uid=pkidbuser,ou=people,o=ipaca" user, with this value: "CN=CA Subsystem,O=SUB.DOMAIN.TLD" (substitute O=SUB.DOMAIN.TLD with your own REALM name, obviously).
 +
 +
So the solution is quite simple. We need to populate the seeAlso attribute of the user10 account with this value:
 +
 +
<pre>
 +
cn=user10,o=SUB.DOMAIN.TLD
 +
</pre>

Revision as of 23:31, 4 March 2016

We can use user certificates to authenticate our ldap session.

generate user certificate for user account

Follow instructions in this blog.

Short version:

  • create csr (certificate signing request).

I usually create a new directory and name it after the name of the user/host we want to create a certificate for. For user10, create a user10 folder.

Inside this folder, create a text file user10.inf like this:

[ req ]
prompt = no
encrypt_key = no

distinguished_name = dn
req_extensions = exts

[ dn ]
commonName = "user10"

[ exts ]
subjectAltName=email:user10@yourdomain.tld
  • generate a key:
openssl genrsa -out user10.key 2048
  • generate the csr:
openssl req -new -key user10.key -out user10.csr -config user10.inf
  • verify csr:
 
openssl req -in user10.csr -text -noout 
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: CN=user10
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c2:d2:0c:44:c8:e3:8b:d7:e5:bc:b6:5d:fc:cf:
                    xxxxx
                Exponent: 65537 (0x10001)
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name: 
                email:user10@yourdomain.tld
    Signature Algorithm: sha1WithRSAEncryption
         05:7b:a7:51:1e:28:25:8d:78:fb:d9:08:43:6d:54:51:db:10:
         xxxxxxxxxxxxxxxxxxxxx
  • request the certificate (as the user self or as an admin user):
$ ipa cert-request user10.csr --principal user10 
....

If everything goes according to plan, you know have a certificate coupled to the user account

$ ipa user-show user10
  User login: user10
  First name: ipa
  Last name: user
  Home directory: /home/user10
  Login shell: /bin/sh
  Email address: user10@yourdomain.tld
  UID: 1076200013
  GID: 1076200013
  Certificate: MIIEMjCCAxqgAwIBAgIBDjANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKDA5VTklYxxxxxxxxxxxxxxxxxxxxxxxxxxxx==
  Account disabled: False
  Password: True
  Member of groups: ipausers
  Kerberos keys available: True
  • retrieve the certificate:

first we need to get the certificate's serial number.

ipa cert-find
...
  Serial number (hex): 0xE
  Serial number: 14
  Status: VALID
  Subject: CN=user10,O=YOURDOMAIN.TLD
<pre>
So, number 14.

<pre> 
ipa cert-show 14 --out user10.pem 
  • eventually, verify certificate:
openssl x509 -in user10.pem -noout -text

which will give you all the certificate output on screen.

map certificate to user account

Canonical info:

http://directory.fedoraproject.org/docs/389ds/howto/howto-certmapping.html

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_SSL-Using_Certificate_Based_Authentication.html

  • verify /etc/dirsrv/slapd-INSTANCE-NAME/certmap.conf looks like this:

</pre> certmap default default

  1. default:DNComps
  2. default:FilterComps e, uid
  3. default:verifycert on
  4. default:CmapLdapAttr certSubjectDN
  5. default:library <path_to_shared_lib_or_dll>
  6. default:InitFn <Init function's name>

default:DNComps default:FilterComps uid certmap ipaca CN=Certificate Authority,O=SUB.DOMAIN.TLD ipaca:CmapLdapAttr seeAlso ipaca:verifycert on </pre>

As you see, there is a 'default' mapping and an 'ipaca' mapping.

WARNING!!!

Do not modify anything of the ipaca mapping unless you know what you are doing. You risk messing up your pki tomcat service and plenty of things will stop working.

WARNING!!!

As you see, the ipaca mapping is your ipa server PKI. It has a CmapLdapAttr mapping attribute to the ldap object attribute seeAlso.

When I searched a test ipa environment, the only account with a seeAlso attribute was the "DN: uid=pkidbuser,ou=people,o=ipaca" user, with this value: "CN=CA Subsystem,O=SUB.DOMAIN.TLD" (substitute O=SUB.DOMAIN.TLD with your own REALM name, obviously).

So the solution is quite simple. We need to populate the seeAlso attribute of the user10 account with this value:

cn=user10,o=SUB.DOMAIN.TLD