From jmagne at redhat.com Fri May 1 01:27:25 2015 From: jmagne at redhat.com (John Magne) Date: Thu, 30 Apr 2015 21:27:25 -0400 (EDT) Subject: [Pki-users] US Government SmartCard question In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7CA9C1@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7C7EAF@001FSN2MPN1-046.001f.mgd2.msft.net> <834675460.8866831.1430173983543.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CA9C1@001FSN2MPN1-046.001f.mgd2.msft.net> Message-ID: <131631231.11235602.1430443645106.JavaMail.zimbra@redhat.com> Thanks for the logs Brian: It might help us to see what coolkey itself is doing, (if anything) when you insert the card. In the same window that you are running the pkcs11_inspect run this: export COOL_KEY_LOG_FILE=/tmp/fileName Hopefully coolkey will write some useful stuff for us there to diagnose. thanks, jack ----- Original Message ----- From: "Bryce L Nordgren -FS" To: "John Magne" Cc: pki-users at redhat.com Sent: Thursday, April 30, 2015 3:22:50 PM Subject: RE: [Pki-users] US Government SmartCard question Hi Jack, thanks for the reply! AFAIK, my card is the same as all other cards issued by USDA, and I suspect the same as all other cards issued by the US Government. It's not a test card or anything. I killed pcscd and ran it on the command line to capture logs (attached). I didn't see anything which set off red flags for me. It looks like it's detecting card insertion and removal events. I'm including the output of "pkcs11_inspect debug", run both as my user account and as root via sudo. All of this was done with coolkey. The cackey module in /etc/pam_pkcs11/pam_pkcs11.conf was commented out. The only real difference between now and previously is that now the light comes on. (Still fails with no token available, tho.) I'm just not seeing anything that points me at a solution. Hope you can intuit more from this. Bryce > -----Original Message----- > From: John Magne [mailto:jmagne at redhat.com] > Sent: Monday, April 27, 2015 4:33 PM > To: Nordgren, Bryce L -FS > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] US Government SmartCard question > > The coolkey pkcs#11 module should provide enough functionality for smart > card login with CAC cards. > I know there is plenty of code in the coolkey driver to handle CACs. Of course > your particular card could be some special case I'm not aware of. > > There are a few things that could be wrong. > > 1. Check to make sure the "psc-lite" daemon is running. > > 2. There might be an issue with your reader. For instance the ccid driver > sometimes needs to be configured to allow for readers that require a higher > voltage such as the omnikey. > > > One thing to try, with coolkey and your card and reader. > > 1. Kill pcscd as root. > > 2. run it manually such that it throws log messages to the console > > /usr/sbin/pcscd -f -d -a. > > 3. Insert the card , watch the logs for any suspicious messages which might > provide a clue. > > If the log says the card is being recognized, then we could possible get some > coolkey logs when you attempt that pkcs11 command mentioned earlier. > > thanks, > jack > > > > ----- Original Message ----- > > From: "Bryce L Nordgren -FS" > > To: pki-users at redhat.com > > Sent: Monday, April 27, 2015 3:06:48 PM > > Subject: [Pki-users] US Government SmartCard question > > > > > > > > Hi, > > > > > > > > I?m trying to set up smart card logins on Linux using a clean Fedora > > 21 install following the instructions at [1]. My main objective is to > > use my USDA-issued LincPass (the USDA brand of the USAccess card) for > > login to local accounts on linux machines that are not joined to the > > domain and which are outside the firewall. Essentially, I have control > > over a handful of machines, but no control over issuing the smart cards. > > > > > > > > I?ll try to get you relevant debugging info, but I don?t know much > > about smart card internals. My setup (card info from ActivClient on > Windows): > > > > > > > > Card Reader: SCR3310 v2.0 ?smartOS powered? > > > > Smart Card Mfr: Oberthur Technologies > > > > Smart Card Model: ID-One Cosmo v7.0 with Oberthur PIV Applet Suite > > 2.3.2 > > > > > > > > The problem: following instructions at [1], ?pkcs11_inspect debug? > > results in ?no token available? and the light on the reader never > > comes on. Googling, I saw that US government cards may require CACKey > > instead of coolkey, so I downloaded/compiled/installed the version at > > [2] and modified the pam_pkcs11.conf file. Reboot. Improvement. The > > light comes on. Repeating the ?pkcs11_inspect debug? prompts for a PIN > > for token, and fails immediately afterward with ?pkcs11_pass_login() > > failed: pkcs11_login() failed?. I entered the PIN I enter on Windows. > > > > > > > > Any insights are appreciated. > > > > > > > > Thanks, > > > > Bryce > > > > > > > > > > > > [1] > > https://docs.fedoraproject.org/en- > US/Fedora/19/html/Security_Guide/sec > > t-Security_Guide-Single_Sign_on_SSO- > Getting_Started_with_your_new_Smar > > t_Card.html > > > > [2] https://github.com/Conservatory/CACKey > > > > _______________________________________________ > > Pki-users mailing list > > Pki-users at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-users From jmagne at redhat.com Fri May 1 01:28:05 2015 From: jmagne at redhat.com (John Magne) Date: Thu, 30 Apr 2015 21:28:05 -0400 (EDT) Subject: [Pki-users] US Government SmartCard question In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7CA9C1@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7C7EAF@001FSN2MPN1-046.001f.mgd2.msft.net> <834675460.8866831.1430173983543.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CA9C1@001FSN2MPN1-046.001f.mgd2.msft.net> Message-ID: <2075904384.11235701.1430443685103.JavaMail.zimbra@redhat.com> All of that I sent goes, except using the wrong name Bryce! :) ----- Original Message ----- From: "Bryce L Nordgren -FS" To: "John Magne" Cc: pki-users at redhat.com Sent: Thursday, April 30, 2015 3:22:50 PM Subject: RE: [Pki-users] US Government SmartCard question Hi Jack, thanks for the reply! AFAIK, my card is the same as all other cards issued by USDA, and I suspect the same as all other cards issued by the US Government. It's not a test card or anything. I killed pcscd and ran it on the command line to capture logs (attached). I didn't see anything which set off red flags for me. It looks like it's detecting card insertion and removal events. I'm including the output of "pkcs11_inspect debug", run both as my user account and as root via sudo. All of this was done with coolkey. The cackey module in /etc/pam_pkcs11/pam_pkcs11.conf was commented out. The only real difference between now and previously is that now the light comes on. (Still fails with no token available, tho.) I'm just not seeing anything that points me at a solution. Hope you can intuit more from this. Bryce > -----Original Message----- > From: John Magne [mailto:jmagne at redhat.com] > Sent: Monday, April 27, 2015 4:33 PM > To: Nordgren, Bryce L -FS > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] US Government SmartCard question > > The coolkey pkcs#11 module should provide enough functionality for smart > card login with CAC cards. > I know there is plenty of code in the coolkey driver to handle CACs. Of course > your particular card could be some special case I'm not aware of. > > There are a few things that could be wrong. > > 1. Check to make sure the "psc-lite" daemon is running. > > 2. There might be an issue with your reader. For instance the ccid driver > sometimes needs to be configured to allow for readers that require a higher > voltage such as the omnikey. > > > One thing to try, with coolkey and your card and reader. > > 1. Kill pcscd as root. > > 2. run it manually such that it throws log messages to the console > > /usr/sbin/pcscd -f -d -a. > > 3. Insert the card , watch the logs for any suspicious messages which might > provide a clue. > > If the log says the card is being recognized, then we could possible get some > coolkey logs when you attempt that pkcs11 command mentioned earlier. > > thanks, > jack > > > > ----- Original Message ----- > > From: "Bryce L Nordgren -FS" > > To: pki-users at redhat.com > > Sent: Monday, April 27, 2015 3:06:48 PM > > Subject: [Pki-users] US Government SmartCard question > > > > > > > > Hi, > > > > > > > > I?m trying to set up smart card logins on Linux using a clean Fedora > > 21 install following the instructions at [1]. My main objective is to > > use my USDA-issued LincPass (the USDA brand of the USAccess card) for > > login to local accounts on linux machines that are not joined to the > > domain and which are outside the firewall. Essentially, I have control > > over a handful of machines, but no control over issuing the smart cards. > > > > > > > > I?ll try to get you relevant debugging info, but I don?t know much > > about smart card internals. My setup (card info from ActivClient on > Windows): > > > > > > > > Card Reader: SCR3310 v2.0 ?smartOS powered? > > > > Smart Card Mfr: Oberthur Technologies > > > > Smart Card Model: ID-One Cosmo v7.0 with Oberthur PIV Applet Suite > > 2.3.2 > > > > > > > > The problem: following instructions at [1], ?pkcs11_inspect debug? > > results in ?no token available? and the light on the reader never > > comes on. Googling, I saw that US government cards may require CACKey > > instead of coolkey, so I downloaded/compiled/installed the version at > > [2] and modified the pam_pkcs11.conf file. Reboot. Improvement. The > > light comes on. Repeating the ?pkcs11_inspect debug? prompts for a PIN > > for token, and fails immediately afterward with ?pkcs11_pass_login() > > failed: pkcs11_login() failed?. I entered the PIN I enter on Windows. > > > > > > > > Any insights are appreciated. > > > > > > > > Thanks, > > > > Bryce > > > > > > > > > > > > [1] > > https://docs.fedoraproject.org/en- > US/Fedora/19/html/Security_Guide/sec > > t-Security_Guide-Single_Sign_on_SSO- > Getting_Started_with_your_new_Smar > > t_Card.html > > > > [2] https://github.com/Conservatory/CACKey > > > > _______________________________________________ > > Pki-users mailing list > > Pki-users at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-users From bnordgren at fs.fed.us Fri May 1 18:13:01 2015 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Fri, 1 May 2015 18:13:01 +0000 Subject: [Pki-users] US Government SmartCard question In-Reply-To: <2075904384.11235701.1430443685103.JavaMail.zimbra@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7C7EAF@001FSN2MPN1-046.001f.mgd2.msft.net> <834675460.8866831.1430173983543.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CA9C1@001FSN2MPN1-046.001f.mgd2.msft.net> <2075904384.11235701.1430443685103.JavaMail.zimbra@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7CABF5@001FSN2MPN1-046.001f.mgd2.msft.net> Hi Jack, I wasn't quite sure how to capture an insertion event with pkcs11_inspect. It seems to fail right away if nothing's in the reader. So I ran "pkcs11_eventmgr debug nodaemon" in the terminal that had the COOL_KEY_LOG_FILE variable set. I also ran a pkcs11_inspect with a card already inserted. Log files for both runs are attached. It's not super verbose, but the root cause seems to be "CAC Select failed". Does this shed any light on the problem? Thanks, Bryce -------------- next part -------------- A non-text attachment was scrubbed... Name: coolkey_eventmgr.log Type: application/octet-stream Size: 1038 bytes Desc: coolkey_eventmgr.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: coolkey_inspect.log Type: application/octet-stream Size: 700 bytes Desc: coolkey_inspect.log URL: From jmagne at redhat.com Fri May 1 18:33:34 2015 From: jmagne at redhat.com (John Magne) Date: Fri, 1 May 2015 14:33:34 -0400 (EDT) Subject: [Pki-users] US Government SmartCard question In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7CABF5@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7C7EAF@001FSN2MPN1-046.001f.mgd2.msft.net> <834675460.8866831.1430173983543.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CA9C1@001FSN2MPN1-046.001f.mgd2.msft.net> <2075904384.11235701.1430443685103.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CABF5@001FSN2MPN1-046.001f.mgd2.msft.net> Message-ID: <1207380858.12444670.1430505214700.JavaMail.zimbra@redhat.com> Bryce: Yes, that helps. I can take a look at the code when I get a moment. Also we might bring in Bob Relyea rrelyea at redhat.com since he is the coolkey and coolkey/CAC guru. ----- Original Message ----- From: "Bryce L Nordgren -FS" To: "John Magne" Cc: pki-users at redhat.com Sent: Friday, May 1, 2015 11:13:01 AM Subject: RE: [Pki-users] US Government SmartCard question Hi Jack, I wasn't quite sure how to capture an insertion event with pkcs11_inspect. It seems to fail right away if nothing's in the reader. So I ran "pkcs11_eventmgr debug nodaemon" in the terminal that had the COOL_KEY_LOG_FILE variable set. I also ran a pkcs11_inspect with a card already inserted. Log files for both runs are attached. It's not super verbose, but the root cause seems to be "CAC Select failed". Does this shed any light on the problem? Thanks, Bryce From bnordgren at fs.fed.us Fri May 1 19:26:12 2015 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Fri, 1 May 2015 19:26:12 +0000 Subject: [Pki-users] US Government SmartCard question In-Reply-To: <1207380858.12444670.1430505214700.JavaMail.zimbra@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7C7EAF@001FSN2MPN1-046.001f.mgd2.msft.net> <834675460.8866831.1430173983543.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CA9C1@001FSN2MPN1-046.001f.mgd2.msft.net> <2075904384.11235701.1430443685103.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CABF5@001FSN2MPN1-046.001f.mgd2.msft.net> <1207380858.12444670.1430505214700.JavaMail.zimbra@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7CAC60@001FSN2MPN1-046.001f.mgd2.msft.net> Jack, I don't know the process or if it's possible yet, but would it help if I could get you guys a dummy LincPass (USDA-issued PIV smart card) with a throwaway PIN to debug with? I've often found that eliminating ignorant middlemen (me) speeds solutions along. Ideally, the card would be usable for console logins as well as our public facing SAML IdP [1]. Is there an extra step to making the card usable with a browser or would a coolkey fix apply to both pam_pkcs11 and the browser? Thanks, Bryce [1] https://www.eauth.usda.gov/Login/login.aspx > -----Original Message----- > From: John Magne [mailto:jmagne at redhat.com] > Sent: Friday, May 01, 2015 12:34 PM > To: Nordgren, Bryce L -FS > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] US Government SmartCard question > > Bryce: > > Yes, that helps. > I can take a look at the code when I get a moment. > Also we might bring in Bob Relyea rrelyea at redhat.com since he is the > coolkey and coolkey/CAC guru. > > > ----- Original Message ----- > From: "Bryce L Nordgren -FS" > To: "John Magne" > Cc: pki-users at redhat.com > Sent: Friday, May 1, 2015 11:13:01 AM > Subject: RE: [Pki-users] US Government SmartCard question > > Hi Jack, > > I wasn't quite sure how to capture an insertion event with pkcs11_inspect. It > seems to fail right away if nothing's in the reader. So I ran "pkcs11_eventmgr > debug nodaemon" in the terminal that had the COOL_KEY_LOG_FILE variable > set. I also ran a pkcs11_inspect with a card already inserted. Log files for both > runs are attached. > > It's not super verbose, but the root cause seems to be "CAC Select failed". > > Does this shed any light on the problem? > > Thanks, > Bryce From Emily at arcananet.com Fri May 1 19:34:50 2015 From: Emily at arcananet.com (Emily Stemmerich) Date: Fri, 1 May 2015 19:34:50 +0000 Subject: [Pki-users] SCEP directory authentication Message-ID: Hi, I was wondering if anyone could offer some assistance with getting SCEP working with LDAP auth? Thanks! -Emily Date: Monday, April 27, 2015 at 4:53 PM To: "pki-users at redhat.com" > Subject: [Pki-users] SCEP directory authentication Hi, I am still trying to get Dogtag 10.2.1 on Fedora 21 working to allow for router identity certificates obtained by Cisco Routers via SCEP to be auto-renewing. I have found that the one-time pin model doesn?t work for auto-renewal. I was pointed to the RedHat document below that discusses using directory-based auth in Section 8.2.1, but I?m having issues with getting it to work. https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Automated_Enrollment.html#Setting_up_Directory_Based_Authentication I?m not certain what to put in the dnpattern attribute and there are no examples I can find and am wondering if it is the reason attempts show uid and credentials as null from the router ? details of the setup later on in this email. * dnpattern. Specifies a string representing a subject name pattern to formulate from the directory attributes and entry DN. ------------------------------------------ >From my CS.conf (RouterAuth is then referenced in the caRouterCert.cfg instead of flatfile): auths.instance.RouterAuth.pluginName=UidPwdDirAuth auths.instance.RouterAuth.ldap.basedn=ou=RouterID,dc=auth,dc=sample,dc=com auths.instance.RouterAuth.ldap.ldapconn.host=localhost auths.instance.RouterAuth.ldap.ldapconn.port=389 auths.instance.RouterAuth.ldap.ldapconn.secureConn=false ------------------------------------------ I?ve created a hierarchy outside of dogtag for doing router auth: ou=RouterID,dc=auth,dc=sample,dc=com ------------------------------------------ Test User Account (I am not sure what objectClass to use, so I found one with uid and password as options and used that): dn: uid=172.18.240.11,ou=RouterID,dc=auth,dc=sample,dc=com uid: 172.18.240.11 objectClass: inetUser userPassword: testpass ------------------------------------------ Router config. For flatfile auth it ends up using the wan IP and the password and password in the identity section, however for LDAP auth I don?t know what things would map to: crypto ca identity SAMPLE enrollment url http://172.21.4.239:8080/ca/cgi-bin revocation-check none fqdn emilyvpn.sample.com serial-number none ip-address none hash sha256 password testpass rsakeypair MEVO 2048 auto-enroll 75 crl optional exit crypto ca authenticate SAMPLE ------------------------------------------ When I try and get a cert from the Cisco Router I get output like the following in the debug file that lists both UID and credential as null: [24/Apr/2015:16:31:18][http-bio-8080-exec-7]: Got authenticator=com.netscape.cms.authentication.UidPwdDirAuthentication [24/Apr/2015:16:31:18][http-bio-8080-exec-7]: LdapAnonConnFactory::getConn [24/Apr/2015:16:31:18][http-bio-8080-exec-7]: LdapAnonConnFactory.getConn(): num avail conns now 4 [24/Apr/2015:16:31:18][http-bio-8080-exec-7]: Authenticating UID=null [24/Apr/2015:16:31:19][http-bio-8080-exec-7]: returnConn: mNumConns now 4 [24/Apr/2015:16:31:19][http-bio-8080-exec-7]: operation failure - Authentication credential for uid is null. [24/Apr/2015:16:31:19][http-bio-8080-exec-7]: Output PKIOperation response: Thanks for any assistance, -Emily -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Fri May 1 21:01:30 2015 From: jmagne at redhat.com (John Magne) Date: Fri, 1 May 2015 17:01:30 -0400 (EDT) Subject: [Pki-users] US Government SmartCard question In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7CAC60@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7C7EAF@001FSN2MPN1-046.001f.mgd2.msft.net> <834675460.8866831.1430173983543.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CA9C1@001FSN2MPN1-046.001f.mgd2.msft.net> <2075904384.11235701.1430443685103.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CABF5@001FSN2MPN1-046.001f.mgd2.msft.net> <1207380858.12444670.1430505214700.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CAC60@001FSN2MPN1-046.001f.mgd2.msft.net> Message-ID: <1916078140.12900740.1430514090664.JavaMail.zimbra@redhat.com> Bryce: We would most welcome a chance to try a dummy card. I think we should copy Bob first to make sure there is not something obvious wrong on the coolkey end. ----- Original Message ----- > From: "Bryce L Nordgren -FS" > To: "John Magne" , rrelyea at redhat.com > Cc: pki-users at redhat.com > Sent: Friday, May 1, 2015 12:26:12 PM > Subject: RE: [Pki-users] US Government SmartCard question > > Jack, > > I don't know the process or if it's possible yet, but would it help if I > could get you guys a dummy LincPass (USDA-issued PIV smart card) with a > throwaway PIN to debug with? I've often found that eliminating ignorant > middlemen (me) speeds solutions along. > > Ideally, the card would be usable for console logins as well as our public > facing SAML IdP [1]. Is there an extra step to making the card usable with a > browser or would a coolkey fix apply to both pam_pkcs11 and the browser? > > Thanks, > Bryce > > [1] https://www.eauth.usda.gov/Login/login.aspx > > > -----Original Message----- > > From: John Magne [mailto:jmagne at redhat.com] > > Sent: Friday, May 01, 2015 12:34 PM > > To: Nordgren, Bryce L -FS > > Cc: pki-users at redhat.com > > Subject: Re: [Pki-users] US Government SmartCard question > > > > Bryce: > > > > Yes, that helps. > > I can take a look at the code when I get a moment. > > Also we might bring in Bob Relyea rrelyea at redhat.com since he is the > > coolkey and coolkey/CAC guru. > > > > > > ----- Original Message ----- > > From: "Bryce L Nordgren -FS" > > To: "John Magne" > > Cc: pki-users at redhat.com > > Sent: Friday, May 1, 2015 11:13:01 AM > > Subject: RE: [Pki-users] US Government SmartCard question > > > > Hi Jack, > > > > I wasn't quite sure how to capture an insertion event with pkcs11_inspect. > > It > > seems to fail right away if nothing's in the reader. So I ran > > "pkcs11_eventmgr > > debug nodaemon" in the terminal that had the COOL_KEY_LOG_FILE variable > > set. I also ran a pkcs11_inspect with a card already inserted. Log files > > for both > > runs are attached. > > > > It's not super verbose, but the root cause seems to be "CAC Select failed". > > > > Does this shed any light on the problem? > > > > Thanks, > > Bryce > From jmagne at redhat.com Fri May 1 21:03:36 2015 From: jmagne at redhat.com (John Magne) Date: Fri, 1 May 2015 17:03:36 -0400 (EDT) Subject: [Pki-users] US Government SmartCard question In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7CABF5@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7C7EAF@001FSN2MPN1-046.001f.mgd2.msft.net> <834675460.8866831.1430173983543.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CA9C1@001FSN2MPN1-046.001f.mgd2.msft.net> <2075904384.11235701.1430443685103.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CABF5@001FSN2MPN1-046.001f.mgd2.msft.net> Message-ID: <276987819.12901272.1430514216091.JavaMail.zimbra@redhat.com> Bob here is a cookley trace from Bryce's failed attempt to use his CAC card with coolkey. Both coolkeySelect and CACSelect appear to be failing, hopefully you might have thoughts. thanks, jack ----- Original Message ----- From: "Bryce L Nordgren -FS" To: "John Magne" Cc: pki-users at redhat.com Sent: Friday, May 1, 2015 11:13:01 AM Subject: RE: [Pki-users] US Government SmartCard question Hi Jack, I wasn't quite sure how to capture an insertion event with pkcs11_inspect. It seems to fail right away if nothing's in the reader. So I ran "pkcs11_eventmgr debug nodaemon" in the terminal that had the COOL_KEY_LOG_FILE variable set. I also ran a pkcs11_inspect with a card already inserted. Log files for both runs are attached. It's not super verbose, but the root cause seems to be "CAC Select failed". Does this shed any light on the problem? Thanks, Bryce -------------- next part -------------- A non-text attachment was scrubbed... Name: coolkey_eventmgr.log Type: text/x-log Size: 1038 bytes Desc: coolkey_eventmgr.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: coolkey_inspect.log Type: text/x-log Size: 700 bytes Desc: coolkey_inspect.log URL: From bnordgren at fs.fed.us Fri May 1 21:49:18 2015 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Fri, 1 May 2015 21:49:18 +0000 Subject: [Pki-users] US Government SmartCard question In-Reply-To: <5543EF4E.1010108@REDHAT.COM> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7C7EAF@001FSN2MPN1-046.001f.mgd2.msft.net> <834675460.8866831.1430173983543.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CA9C1@001FSN2MPN1-046.001f.mgd2.msft.net> <2075904384.11235701.1430443685103.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CABF5@001FSN2MPN1-046.001f.mgd2.msft.net> <1207380858.12444670.1430505214700.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CAC60@001FSN2MPN1-046.001f.mgd2.msft.net> <1916078140.12900740.1430514090664.JavaMail.zimbra@redhat.com> <5543EF4E.1010108@REDHAT.COM> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7CAD26@001FSN2MPN1-046.001f.mgd2.msft.net> I will start poking around to see if I can't get a dummy card. Since I'm just a lowly user it may take some wheedling. Honestly, anything I tell you would be guesswork and hearsay. Our SAML IdP [1] talks about it like it's a PIV. The General Services Administration operates the centers where we go get them issued, and across the civilian agencies, they are known as "USAccess" credentials. [2] I really couldn't tell you whether we're compatible with DoD cards (which guesswork and hearsay leads me to believe is the source of the CAC acronym). [1] https://www.eauth.usda.gov/Login/login.aspx [2] http://www.gsa.gov/portal/category/27240 > -----Original Message----- > From: Robert Relyea [mailto:rrelyea at redhat.com] > Sent: Friday, May 01, 2015 3:26 PM > To: John Magne; Nordgren, Bryce L -FS > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] US Government SmartCard question > > On 05/01/2015 02:01 PM, John Magne wrote: > > Bryce: > > > > We would most welcome a chance to try a dummy card. > > I think we should copy Bob first to make sure there is not something > > obvious wrong on the coolkey end. > > I usually insist on a dummy card because we are always making changes to > coolkey and if I have a dummy card, I can test against that card when I > add additional card support. > > BTW is this a PIV or CAC card? You meantion PIV here, but Jack was > speaking as if this were a CAC card. > > bob > > > > > > > > ----- Original Message ----- > >> From: "Bryce L Nordgren -FS" > >> To: "John Magne" , rrelyea at redhat.com > >> Cc: pki-users at redhat.com > >> Sent: Friday, May 1, 2015 12:26:12 PM > >> Subject: RE: [Pki-users] US Government SmartCard question > >> > >> Jack, > >> > >> I don't know the process or if it's possible yet, but would it help if I > >> could get you guys a dummy LincPass (USDA-issued PIV smart card) with a > >> throwaway PIN to debug with? I've often found that eliminating ignorant > >> middlemen (me) speeds solutions along. > >> > >> Ideally, the card would be usable for console logins as well as our public > >> facing SAML IdP [1]. Is there an extra step to making the card usable with > a > >> browser or would a coolkey fix apply to both pam_pkcs11 and the > browser? > >> > >> Thanks, > >> Bryce > >> > >> [1] https://www.eauth.usda.gov/Login/login.aspx > >> > >>> -----Original Message----- > >>> From: John Magne [mailto:jmagne at redhat.com] > >>> Sent: Friday, May 01, 2015 12:34 PM > >>> To: Nordgren, Bryce L -FS > >>> Cc: pki-users at redhat.com > >>> Subject: Re: [Pki-users] US Government SmartCard question > >>> > >>> Bryce: > >>> > >>> Yes, that helps. > >>> I can take a look at the code when I get a moment. > >>> Also we might bring in Bob Relyea rrelyea at redhat.com since he is the > >>> coolkey and coolkey/CAC guru. > >>> > >>> > >>> ----- Original Message ----- > >>> From: "Bryce L Nordgren -FS" > >>> To: "John Magne" > >>> Cc: pki-users at redhat.com > >>> Sent: Friday, May 1, 2015 11:13:01 AM > >>> Subject: RE: [Pki-users] US Government SmartCard question > >>> > >>> Hi Jack, > >>> > >>> I wasn't quite sure how to capture an insertion event with > pkcs11_inspect. > >>> It > >>> seems to fail right away if nothing's in the reader. So I ran > >>> "pkcs11_eventmgr > >>> debug nodaemon" in the terminal that had the COOL_KEY_LOG_FILE > variable > >>> set. I also ran a pkcs11_inspect with a card already inserted. Log files > >>> for both > >>> runs are attached. > >>> > >>> It's not super verbose, but the root cause seems to be "CAC Select > failed". > >>> > >>> Does this shed any light on the problem? > >>> > >>> Thanks, > >>> Bryce > From bnordgren at fs.fed.us Fri May 1 23:05:16 2015 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Fri, 1 May 2015 23:05:16 +0000 Subject: [Pki-users] US Government SmartCard question In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7CAD26@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7C7EAF@001FSN2MPN1-046.001f.mgd2.msft.net> <834675460.8866831.1430173983543.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CA9C1@001FSN2MPN1-046.001f.mgd2.msft.net> <2075904384.11235701.1430443685103.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CABF5@001FSN2MPN1-046.001f.mgd2.msft.net> <1207380858.12444670.1430505214700.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CAC60@001FSN2MPN1-046.001f.mgd2.msft.net> <1916078140.12900740.1430514090664.JavaMail.zimbra@redhat.com> <5543EF4E.1010108@REDHAT.COM> <82E7C9A01FD0764CACDD35D10F5DFB6E7CAD26@001FSN2MPN1-046.001f.mgd2.msft.net> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7CAD6B@001FSN2MPN1-046.001f.mgd2.msft.net> Bob, First, I think the standard which applies to my card may be FIPS 201, not CAC. Again with the hearsay. Second, I think I found the way to get: a] cards to test; and b] coolkey included on the GSA list of approved products. Could you take a look at [1] and tell me if this has what you need? From what I can tell, this may be a lot more official than me mailing you a card. Bryce [1] http://www.idmanagement.gov/ficam-testing-program From cfu at redhat.com Fri May 1 23:30:10 2015 From: cfu at redhat.com (Christina Fu) Date: Fri, 01 May 2015 16:30:10 -0700 Subject: [Pki-users] SCEP directory authentication In-Reply-To: References: Message-ID: <55440C82.3090007@redhat.com> Hi Emily, By default SCEP could take a challengePassword (internally "challengePhrase") that you could map with the host id, which is what the FlatFile authentication does. However, the directory based authenticator handles literally "uid" and "pwd". You will need to get challengePhrase mapped to pwd into the request, and to do that you could write a plugin for it. I think you could try editing the following file server/cms/src/com/netscape/cms/servlet/cert/scep/CRSEnrollment.java to get "uid" and "pwd' filled in the request. We have professional services that could help write plugins. Christina On 05/01/2015 12:34 PM, Emily Stemmerich wrote: > Hi, > > I was wondering if anyone could offer some assistance with getting > SCEP working with LDAP auth? > > Thanks! > -Emily > > Date: Monday, April 27, 2015 at 4:53 PM > To: "pki-users at redhat.com " > > > Subject: [Pki-users] SCEP directory authentication > > Hi, > > I am still trying to get Dogtag 10.2.1 on Fedora 21 working to allow > for router identity certificates obtained by Cisco Routers via SCEP to > be auto-renewing. I have found that the one-time pin model doesn?t > work for auto-renewal. I was pointed to the RedHat document below > that discusses using directory-based auth in Section 8.2.1, but I?m > having issues with getting it to work. > > https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Automated_Enrollment.html#Setting_up_Directory_Based_Authentication > > I?m not certain what to put in the dnpattern attribute and there are > no examples I can find and am wondering if it is the reason attempts > show uid and credentials as null from the router ? details of the > setup later on in this email. > > * > *dnpattern.* Specifies a string representing a subject name > pattern to formulate from the directory attributes and entry DN. > > ------------------------------------------ > > From my CS.conf (RouterAuth is then referenced in the caRouterCert.cfg > instead of flatfile): > > auths.instance.RouterAuth.pluginName=UidPwdDirAuth > auths.instance.RouterAuth.ldap.basedn=ou=RouterID,dc=auth,dc=sample,dc=com > auths.instance.RouterAuth.ldap.ldapconn.host=localhost > auths.instance.RouterAuth.ldap.ldapconn.port=389 > auths.instance.RouterAuth.ldap.ldapconn.secureConn=false > ------------------------------------------ > > I?ve created a hierarchy outside of dogtag for doing router auth: > ou=RouterID,dc=auth,dc=sample,dc=com > ------------------------------------------ > > Test User Account (I am not sure what objectClass to use, so I found > one with uid and password as options and used that): > dn: uid=172.18.240.11,ou=RouterID,dc=auth,dc=sample,dc=com > uid: 172.18.240.11 > |objectClass: inetUser| > userPassword: testpass > > ------------------------------------------ > Router config. For flatfile auth it ends up using the wan IP and the > password and password in the identity section, however for LDAP auth I > don?t know what things would map to: > > crypto ca identity SAMPLE > enrollment url http://172.21.4.239:8080/ca/cgi-bin > revocation-check none > fqdn emilyvpn.sample.com > serial-number none > ip-address none > hash sha256 > password testpass > rsakeypair MEVO 2048 > auto-enroll 75 > crl optional > exit > > crypto ca authenticate SAMPLE > > ------------------------------------------ > > When I try and get a cert from the Cisco Router I get output like the > following in the debug file that lists both UID and credential as null: > > [24/Apr/2015:16:31:18][http-bio-8080-exec-7]: Got > authenticator=com.netscape.cms.authentication.UidPwdDirAuthentication > [24/Apr/2015:16:31:18][http-bio-8080-exec-7]: LdapAnonConnFactory::getConn > [24/Apr/2015:16:31:18][http-bio-8080-exec-7]: > LdapAnonConnFactory.getConn(): num avail conns now 4 > [24/Apr/2015:16:31:18][http-bio-8080-exec-7]: Authenticating UID=null > [24/Apr/2015:16:31:19][http-bio-8080-exec-7]: returnConn: mNumConns now 4 > [24/Apr/2015:16:31:19][http-bio-8080-exec-7]: operation failure - > Authentication credential for uid is null. > [24/Apr/2015:16:31:19][http-bio-8080-exec-7]: Output PKIOperation > response: > > Thanks for any assistance, > -Emily > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.elkhalidi at gmail.com Sat May 2 18:34:59 2015 From: ali.elkhalidi at gmail.com (Ali Khalidi) Date: Sat, 2 May 2015 21:34:59 +0300 Subject: [Pki-users] confused about access control list In-Reply-To: <55410DFD.9010602@redhat.com> References: <553A6FCD.6080507@redhat.com> <55410DFD.9010602@redhat.com> Message-ID: Thanks for taking the time to look at this. Since I was using the pkiconsole, I actually had two separate entries: one for all uses (default), and one to deny that particular user, thinking that they will be evaluated together, with deny rules have precedence over allow rules. apparently, I was wrong, please confirm. I've modified the rule to the one you mentioned, but unfortunately it did not accomplish the required result, as well. looking into the debug log, I noticed that profile based enrollment does not get mapped to a specific Authentication or Authorization. so, no matter what ACL I put it will not have any effect. moreover, since the mapping does not exists, even the confi files: acl.properties or auth-method.properties have no effect as well. The last line in the log (preceded by a line of dashes) is somehow confusing, and I was wondering how would you ACL caProfileSubmit through LDAP? isn't the resourceACL LDAP as well?! reference is this REST mapping: https://git.fedorahosted.org/cgit/pki.git/plain/base/common/src/com/netscape/certsrv/cert/CertRequestResource.java now, the debug log: [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: AccountResource.login() [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: mapping: account [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: loading /usr/share/pki/ca/conf/auth-method.properties [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: checking /var/lib/pki/cse-ca/ca/conf/auth-method.properties [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: required auth methods: [passwdUserDBAuthMgr, certUserDBAuthMgr] [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: authentication manager: certUserDBAuthMgr [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: access granted [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: AccountResource.login() [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: mapping: account.login [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: principal: caagent [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: loading /usr/share/pki/ca/conf/acl.properties [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: checking /var/lib/pki/cse-ca/ca/conf/acl.properties [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: ACL: certServer.ca.account,login [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: checkACLS(): ACLEntry expressions= user="anybody" [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: evaluating expressions: user="anybody" [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: evaluated expression: user="anybody" to be true [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: DirAclAuthz: authorization passed [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: access granted ****BEGIN SEGMENT OF INTEREST**** [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor: CertRequestResource.enrollCert() [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor: mapping: default [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor: required auth methods: [*] [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor: authentication manager: certUserDBAuthMgr [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor: access granted [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: ACLInterceptor: CertRequestResource.enrollCert() [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: ACLInterceptor: No ACL mapping. ----------------------------------------------------------------------------------------------------------------------------------------------- [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: according to ccMode, authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, use default authz mgr: {2}. ****END SEGMENT OF INTEREST**** thanks, On Wed, Apr 29, 2015 at 7:59 PM, Christina Fu wrote: > Hi, > I was looking for an exact aci syntax example you tried that failed so I > could help you better with. > Did you do something like: > resourceACLS: certServer.ee.request.enrollment:submit:allow (submit) > user!="someBody" && group="Agents":All Agents other than someBody may submit > an enrollment request > > I got the syntax info from the link I gave you. Let me know if that's what > you tried. > > Christina > > > On 04/24/2015 11:14 AM, Ali Khalidi wrote: > > In my test, I've added an user to CM and assigned him Agent group > permissions. > now, I want to deny this user enrollment submission, so there are two > default and pre-existing ACLs of relevance: > certServer.ca.request.enrollment and certServer.ee.request.enrollment > in both I tried the following to the submit right: > change the submit right from allow to deny -> the user can still submit and > enroll a certificate > change back to allow, then added a deny rule with the username specified -> > the user can still submit and enroll a certificate > > these were just experiments to understand how ACLs work. > > my end goal, if possible with dogtag, and I would appreciate if you point me > to the right direction is: > restrict an agent to submit and execute and enrollment based on a specific > certificate profile. > > having said the latter, the user_origreq looked promising for that matter, > but I have no clue how to create a new ACL with it. help is appreciated in > the area as well. > > > Thanks, > > Ali > > > > > > > > On Fri, Apr 24, 2015 at 7:31 PM, Christina Fu wrote: >> >> >> On 04/22/2015 02:17 AM, Ali Khalidi wrote: >> >> I've tried a simple example of using the ACL to block profile listing and >> it works. however, I want to disable a CA agent from submitting/approving or >> executing any enrollment requests. I've went through all the ACLs, and >> whenever I encountered a submit right, I flipped to deny. despite that the >> agent still is able to submit and enroll certificates. >> >> information on access control can be found here: >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Authorization_for_CRTS_Users.html >> >> It would help if you give us an acl example that you tried that does not >> work? >> >> >> another aspect, I was looking into the user_orgreq ACL plugin. can someone >> provide and an example on how this can be used in the context of ACLs? >> >> >> The user_origreq is an access evaluator plugin for the >> UserOrigReqAccessEvaluator. Its primary purpose is for access control >> during renewal. It checks to see the the authenticated user and the >> original request ownership match. >> >> Hope this helps. >> >> >> thanks, >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > > > From cfu at redhat.com Wed May 6 01:51:48 2015 From: cfu at redhat.com (Christina Fu) Date: Tue, 05 May 2015 18:51:48 -0700 Subject: [Pki-users] confused about access control list In-Reply-To: References: <553A6FCD.6080507@redhat.com> <55410DFD.9010602@redhat.com> Message-ID: <554973B4.4050600@redhat.com> Hi, I did not know you were using the REST interface. I actually have not used the REST interface pki commands much but I can try to reproduce and investigate if you could give me the following info: 1. what exact ACL did you change and how you changed it? 2. What command did you use (how exactly did you use it) that resulted in the log? As I'm really not familiar with these new cli's it would help speed up if you could provide as much detail as possible. Regardless of the interface, the profile framework actually allows one to specify *per profile* authentication and authorization. you can look in any existing profile and see the following parameters and values. auth.instance_id authz.acl Christina On 05/02/2015 11:34 AM, Ali Khalidi wrote: > Thanks for taking the time to look at this. > > Since I was using the pkiconsole, I actually had two separate entries: > one for all uses (default), and one to deny that particular user, > thinking that they will be evaluated together, with deny rules have > precedence over allow rules. apparently, I was wrong, please confirm. > > I've modified the rule to the one you mentioned, but unfortunately it > did not accomplish the required result, as well. > > looking into the debug log, I noticed that profile based enrollment > does not get mapped to a specific Authentication or Authorization. so, > no matter what ACL I put it will not have any effect. moreover, since > the mapping does not exists, even the confi files: acl.properties or > auth-method.properties have no effect as well. > > The last line in the log (preceded by a line of dashes) is somehow > confusing, and I was wondering how would you ACL caProfileSubmit > through LDAP? isn't the resourceACL LDAP as well?! > > reference is this REST mapping: > https://git.fedorahosted.org/cgit/pki.git/plain/base/common/src/com/netscape/certsrv/cert/CertRequestResource.java > > now, the debug log: > > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: > AccountResource.login() > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: > mapping: account > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: > loading /usr/share/pki/ca/conf/auth-method.properties > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: > checking /var/lib/pki/cse-ca/ca/conf/auth-method.properties > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: > required auth methods: [passwdUserDBAuthMgr, certUserDBAuthMgr] > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: > authentication manager: certUserDBAuthMgr > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: AuthMethodInterceptor: > access granted > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: > AccountResource.login() > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: mapping: > account.login > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: principal: caagent > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: loading > /usr/share/pki/ca/conf/acl.properties > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: checking > /var/lib/pki/cse-ca/ca/conf/acl.properties > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: ACL: > certServer.ca.account,login > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: checkACLS(): ACLEntry > expressions= user="anybody" > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: evaluating expressions: > user="anybody" > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: evaluated expression: > user="anybody" to be true > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: DirAclAuthz: authorization passed > [30/Apr/2015:09:08:50][http-bio-8443-exec-1]: ACLInterceptor: access granted > ****BEGIN SEGMENT OF INTEREST**** > [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor: > CertRequestResource.enrollCert() > [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor: > mapping: default > [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor: > required auth methods: [*] > [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor: > authentication manager: certUserDBAuthMgr > [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: AuthMethodInterceptor: > access granted > [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: ACLInterceptor: > CertRequestResource.enrollCert() > [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: ACLInterceptor: No ACL mapping. > ----------------------------------------------------------------------------------------------------------------------------------------------- > [30/Apr/2015:09:08:50][http-bio-8443-exec-2]: according to ccMode, > authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, > use default authz mgr: {2}. > ****END SEGMENT OF INTEREST**** > > thanks, > > > On Wed, Apr 29, 2015 at 7:59 PM, Christina Fu wrote: >> Hi, >> I was looking for an exact aci syntax example you tried that failed so I >> could help you better with. >> Did you do something like: >> resourceACLS: certServer.ee.request.enrollment:submit:allow (submit) >> user!="someBody" && group="Agents":All Agents other than someBody may submit >> an enrollment request >> >> I got the syntax info from the link I gave you. Let me know if that's what >> you tried. >> >> Christina >> >> >> On 04/24/2015 11:14 AM, Ali Khalidi wrote: >> >> In my test, I've added an user to CM and assigned him Agent group >> permissions. >> now, I want to deny this user enrollment submission, so there are two >> default and pre-existing ACLs of relevance: >> certServer.ca.request.enrollment and certServer.ee.request.enrollment >> in both I tried the following to the submit right: >> change the submit right from allow to deny -> the user can still submit and >> enroll a certificate >> change back to allow, then added a deny rule with the username specified -> >> the user can still submit and enroll a certificate >> >> these were just experiments to understand how ACLs work. >> >> my end goal, if possible with dogtag, and I would appreciate if you point me >> to the right direction is: >> restrict an agent to submit and execute and enrollment based on a specific >> certificate profile. >> >> having said the latter, the user_origreq looked promising for that matter, >> but I have no clue how to create a new ACL with it. help is appreciated in >> the area as well. >> >> >> Thanks, >> >> Ali >> >> >> >> >> >> >> >> On Fri, Apr 24, 2015 at 7:31 PM, Christina Fu wrote: >>> >>> On 04/22/2015 02:17 AM, Ali Khalidi wrote: >>> >>> I've tried a simple example of using the ACL to block profile listing and >>> it works. however, I want to disable a CA agent from submitting/approving or >>> executing any enrollment requests. I've went through all the ACLs, and >>> whenever I encountered a submit right, I flipped to deny. despite that the >>> agent still is able to submit and enroll certificates. >>> >>> information on access control can be found here: >>> >>> https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Authorization_for_CRTS_Users.html >>> >>> It would help if you give us an acl example that you tried that does not >>> work? >>> >>> >>> another aspect, I was looking into the user_orgreq ACL plugin. can someone >>> provide and an example on how this can be used in the context of ACLs? >>> >>> >>> The user_origreq is an access evaluator plugin for the >>> UserOrigReqAccessEvaluator. Its primary purpose is for access control >>> during renewal. It checks to see the the authenticated user and the >>> original request ownership match. >>> >>> Hope this helps. >>> >>> >>> thanks, >>> >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users >>> >>> >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users >> >> From thibaut.pouzet at lyra-network.com Wed May 6 12:58:15 2015 From: thibaut.pouzet at lyra-network.com (Thibaut Pouzet) Date: Wed, 06 May 2015 14:58:15 +0200 Subject: [Pki-users] XSS attacks on the web administration page (port 9180, port 9444) Message-ID: <554A0FE7.8070402@lyra-network.com> Hi, We are using the dogtag PKI tool packaged through IPA on CentOS 6.6, here are the system information : * pki-ca-9.0.3-38.el6_6.noarch * pki-setup-9.0.3-38.el6_6.noarch $ uname -a Linux ipa_server 2.6.32-504.12.2.el6.x86_64 #1 SMP Wed Mar 11 22:03:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/redhat-release CentOS release 6.6 (Final) It appears that the administation page is vulnerable to XSS attacks, wether through the SSL administration page, or the non-SSL administration page. Here is the PoC : * http://ipa_server:9180/ca/ee/ca/profileSelect?profileId=plop%3C/script%3E%3Cscript%3Evar%20x=document.cookie;alert%28x%29;// * https://ipa_server:9444/ca/ee/ca/profileSelect?profileId=plop%3C/script%3E%3Cscript%3Evar%20x=document.cookie;alert%28x%29;// I cannot seem to find any trace of this problem on google, am I missing something ? Is it the same for other people ? Cheers, -- Thibaut Pouzet Lyra Network Ing?nieur Syst?mes et R?seaux (+33) 5 31 22 40 08 www.lyra-network.com From rrelyea at redhat.com Fri May 1 21:25:34 2015 From: rrelyea at redhat.com (Robert Relyea) Date: Fri, 01 May 2015 14:25:34 -0700 Subject: [Pki-users] US Government SmartCard question In-Reply-To: <1916078140.12900740.1430514090664.JavaMail.zimbra@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7C7EAF@001FSN2MPN1-046.001f.mgd2.msft.net> <834675460.8866831.1430173983543.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CA9C1@001FSN2MPN1-046.001f.mgd2.msft.net> <2075904384.11235701.1430443685103.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CABF5@001FSN2MPN1-046.001f.mgd2.msft.net> <1207380858.12444670.1430505214700.JavaMail.zimbra@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E7CAC60@001FSN2MPN1-046.001f.mgd2.msft.net> <1916078140.12900740.1430514090664.JavaMail.zimbra@redhat.com> Message-ID: <5543EF4E.1010108@REDHAT.COM> On 05/01/2015 02:01 PM, John Magne wrote: > Bryce: > > We would most welcome a chance to try a dummy card. > I think we should copy Bob first to make sure there is not something > obvious wrong on the coolkey end. I usually insist on a dummy card because we are always making changes to coolkey and if I have a dummy card, I can test against that card when I add additional card support. BTW is this a PIV or CAC card? You meantion PIV here, but Jack was speaking as if this were a CAC card. bob > > > > ----- Original Message ----- >> From: "Bryce L Nordgren -FS" >> To: "John Magne" , rrelyea at redhat.com >> Cc: pki-users at redhat.com >> Sent: Friday, May 1, 2015 12:26:12 PM >> Subject: RE: [Pki-users] US Government SmartCard question >> >> Jack, >> >> I don't know the process or if it's possible yet, but would it help if I >> could get you guys a dummy LincPass (USDA-issued PIV smart card) with a >> throwaway PIN to debug with? I've often found that eliminating ignorant >> middlemen (me) speeds solutions along. >> >> Ideally, the card would be usable for console logins as well as our public >> facing SAML IdP [1]. Is there an extra step to making the card usable with a >> browser or would a coolkey fix apply to both pam_pkcs11 and the browser? >> >> Thanks, >> Bryce >> >> [1] https://www.eauth.usda.gov/Login/login.aspx >> >>> -----Original Message----- >>> From: John Magne [mailto:jmagne at redhat.com] >>> Sent: Friday, May 01, 2015 12:34 PM >>> To: Nordgren, Bryce L -FS >>> Cc: pki-users at redhat.com >>> Subject: Re: [Pki-users] US Government SmartCard question >>> >>> Bryce: >>> >>> Yes, that helps. >>> I can take a look at the code when I get a moment. >>> Also we might bring in Bob Relyea rrelyea at redhat.com since he is the >>> coolkey and coolkey/CAC guru. >>> >>> >>> ----- Original Message ----- >>> From: "Bryce L Nordgren -FS" >>> To: "John Magne" >>> Cc: pki-users at redhat.com >>> Sent: Friday, May 1, 2015 11:13:01 AM >>> Subject: RE: [Pki-users] US Government SmartCard question >>> >>> Hi Jack, >>> >>> I wasn't quite sure how to capture an insertion event with pkcs11_inspect. >>> It >>> seems to fail right away if nothing's in the reader. So I ran >>> "pkcs11_eventmgr >>> debug nodaemon" in the terminal that had the COOL_KEY_LOG_FILE variable >>> set. I also ran a pkcs11_inspect with a card already inserted. Log files >>> for both >>> runs are attached. >>> >>> It's not super verbose, but the root cause seems to be "CAC Select failed". >>> >>> Does this shed any light on the problem? >>> >>> Thanks, >>> Bryce -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4264 bytes Desc: S/MIME Cryptographic Signature URL: From dstutzman at caci.com Thu May 14 12:03:02 2015 From: dstutzman at caci.com (David Stutzman - US) Date: Thu, 14 May 2015 12:03:02 +0000 Subject: [Pki-users] OCSP Manager and large CRLs Message-ID: <1431604980004.49799@caci.com> I'm attempting to configure an instance of the standalone OCSP Manager and I'm having an issue with it loading the active set of DoD CAs/CRLs. I'm using the LDAP store and have the 17 active CAs/CRLs (Root 2, ID and Email 25-32) added in the configuration. I loaded the directory server (389 ds) with a java program so I know all entries are configured exactly the same with caCertificate;binary and certificateRevocationList;binary attributes for each. While loading, In the debug logs I see "Started CRL Update" for all 17 but then I'll only see 13 finish. I see increased CPU usage (basically 100%) for several minutes after starting the service until the 14th CRL is processed when the machine goes back to idle and it just seems to stop processing the remaining 3 large CRLs. The problem CRLs are understandably the 4 largest at 27.6Mb (this one loads about 4 min 45 seconds after startup), 30.6Mb, 29.5Mb, 33.5Mb. The virtual machine I'm using has 4 cores and 8GB of memory (originally 4, but increasing to 8 didn't seem to help). I see nothing in the system or transaction logs to indicate what the problem is either. The rpm version of the pki-ocsp package is 9.0.15-1. Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From tangoxix at gmail.com Fri May 15 05:29:19 2015 From: tangoxix at gmail.com (Ben Peck) Date: Fri, 15 May 2015 00:29:19 -0500 Subject: [Pki-users] Can I change the CN = CA Signing Certificate to something else? Message-ID: I'm running Fedora 21 with Dogtag 10.2.1-3. My CA's Certificate was given "CA Signing Certificate" as its CN, and I'm wondering how it got that way and it might be customized on install. Running pkispawn interactively definitely didn't give me an opportunity to supply a name, and looking over the config file I could customize also doesn't seem to provide an opportunity to customize this: Dogtag 9 gave the opportunity to customize this as part of the initial setup - where is this done in version 10? thanks, Ben pki_admin_email=caadmin at example.com pki_admin_name=caadmin pki_admin_nickname=caadmin pki_admin_password=Secret123 pki_admin_uid=caadmin pki_backup_keys=True pki_backup_password=Secret123 pki_client_database_password=Secret123 pki_client_database_purge=False pki_client_pkcs12_password=Secret123 pki_ds_base_dn=dc=ca,dc=example,dc=com pki_ds_database=ca pki_ds_password=Secret123 pki_security_domain_name=EXAMPLE pki_token_password=Secret123 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Fri May 15 06:05:19 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 15 May 2015 16:05:19 +1000 Subject: [Pki-users] Can I change the CN = CA Signing Certificate to something else? In-Reply-To: References: Message-ID: <20150515060519.GN12806@dhcp-40-8.bne.redhat.com> On Fri, May 15, 2015 at 12:29:19AM -0500, Ben Peck wrote: > I'm running Fedora 21 with Dogtag 10.2.1-3. My CA's Certificate was given > "CA Signing Certificate" as its CN, and I'm wondering how it got that way > and it might be customized on install. > > Running pkispawn interactively definitely didn't give me an opportunity to > supply a name, and looking over the config file I could customize also > doesn't seem to provide an opportunity to customize this: > > Dogtag 9 gave the opportunity to customize this as part of the initial > setup - where is this done in version 10? > > thanks, > Ben > Hi Ben, pkispawn(8) does not ask what yo uwant the CN to be, but you can tell it via a configuration file. Minimal pkispawn(8) configuration file: [DEFAULT] pki_admin_password=4me2Test pki_client_database_password=4me2Test pki_client_pkcs12_password=4me2Test pki_ds_password=4me2Test [CA] pki_profiles_in_ldap=True pki_ca_signing_subject_dn=cn=YOUR CN HERE Spawn an instance: $ pkispawn -s CA -f your-config.conf Hope that helps! Fraser > > pki_admin_email=caadmin at example.com > pki_admin_name=caadmin > pki_admin_nickname=caadmin > pki_admin_password=Secret123 > pki_admin_uid=caadmin > pki_backup_keys=True > pki_backup_password=Secret123 > pki_client_database_password=Secret123 > pki_client_database_purge=False > pki_client_pkcs12_password=Secret123 > pki_ds_base_dn=dc=ca,dc=example,dc=com > pki_ds_database=ca > pki_ds_password=Secret123 > pki_security_domain_name=EXAMPLE > pki_token_password=Secret123 > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From tangoxix at gmail.com Fri May 15 15:04:21 2015 From: tangoxix at gmail.com (Ben Peck) Date: Fri, 15 May 2015 10:04:21 -0500 Subject: [Pki-users] Can I change the CN = CA Signing Certificate to something else? In-Reply-To: <20150515060519.GN12806@dhcp-40-8.bne.redhat.com> References: <20150515060519.GN12806@dhcp-40-8.bne.redhat.com> Message-ID: Thanks very much Fraser, I missed that. That's what I was looking for. Ben Peck On Fri, May 15, 2015 at 1:05 AM, Fraser Tweedale wrote: > On Fri, May 15, 2015 at 12:29:19AM -0500, Ben Peck wrote: > > I'm running Fedora 21 with Dogtag 10.2.1-3. My CA's Certificate was given > > "CA Signing Certificate" as its CN, and I'm wondering how it got that way > > and it might be customized on install. > > > > Running pkispawn interactively definitely didn't give me an opportunity > to > > supply a name, and looking over the config file I could customize also > > doesn't seem to provide an opportunity to customize this: > > > > Dogtag 9 gave the opportunity to customize this as part of the initial > > setup - where is this done in version 10? > > > > thanks, > > Ben > > > Hi Ben, > > pkispawn(8) does not ask what yo uwant the CN to be, but you can > tell it via a configuration file. > > Minimal pkispawn(8) configuration file: > > [DEFAULT] > pki_admin_password=4me2Test > pki_client_database_password=4me2Test > pki_client_pkcs12_password=4me2Test > pki_ds_password=4me2Test > > [CA] > pki_profiles_in_ldap=True > pki_ca_signing_subject_dn=cn=YOUR CN HERE > > Spawn an instance: > > $ pkispawn -s CA -f your-config.conf > > Hope that helps! > Fraser > > > > > > pki_admin_email=caadmin at example.com > > pki_admin_name=caadmin > > pki_admin_nickname=caadmin > > pki_admin_password=Secret123 > > pki_admin_uid=caadmin > > pki_backup_keys=True > > pki_backup_password=Secret123 > > pki_client_database_password=Secret123 > > pki_client_database_purge=False > > pki_client_pkcs12_password=Secret123 > > pki_ds_base_dn=dc=ca,dc=example,dc=com > > pki_ds_database=ca > > pki_ds_password=Secret123 > > pki_security_domain_name=EXAMPLE > > pki_token_password=Secret123 > > > _______________________________________________ > > Pki-users mailing list > > Pki-users at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Sat May 16 20:34:25 2015 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Sat, 16 May 2015 20:34:25 +0000 Subject: [Pki-users] PIV-II middleware bug in coolkey Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7D63C6@001FSN2MPN1-044.001f.mgd2.msft.net> Continuation of thread started in: https://www.redhat.com/archives/pki-users/2015-April/msg00041.html Synopsis: coolkey misinterprets my USDA LincPass (issued by a GSA Credentialing Center) as a CAC, then fails. It's a PIV-II, according to OpenSC, which doesn't fail. Using the OpenSC module with pam-pkcs11, I was able to get pklogin_finder to validate my certificates and associate my card to a user account via cn mapper. Using the coolkey module, errors ensued and logs are attached to the above thread. The question is: how do I/should I report this bug? Coolkey looks dead. No svn commits for 4 years. Last mailing list traffic on coolkey-devel was 2012. Is there anyone on the project? In the interim, I was also able to locate a standard deck of test cards [1], both for 30 day loan and for purchase @ $1900. The test deck contains two "golden" cards and 22 cards with known problems that the software should catch. It does not appear I can request an "extra" card from USDA for testing. If there's anyone left to update coolkey, do you think the 30 day loan (potentially with an extension) is enough time to debug the software, or at the very least get a start on it? If the $1900 deck is necessary to add this functionality, it may be possible to donate or semi-permanently loan a set to the open source project. But I'd definitely need to understand what the coolkey project's release and testing plan is and who would hold the physical assets. Thanks, Bryce [1] http://www.idmanagement.gov/ficam-testing-program -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Sat May 16 22:03:17 2015 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Sat, 16 May 2015 22:03:17 +0000 Subject: [Pki-users] ESC doesn't recognize smartcard / standalone operation? Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7D6415@001FSN2MPN1-044.001f.mgd2.msft.net> My system is to the point where command line interaction with the smart card behaves as expected, as long as I use the OpenSC middleware to pam_pkcs11, and not coolkey. Using pklogin_finder asks for the PIN, verifies the certificates, and maps the user to a local system account. System details in previous thread: https://www.redhat.com/archives/pki-users/2015-April/msg00041.html My expectation was that the "smart card manager" should pop up when the card is inserted. It doesn't. I can type "esc" at the command line, and it says "No Cards Present" with everything greyed out. Likewise, inserting the smart card at the login prompt does nothing. There _is_ an "./escd" process running. Is ESC hardwired to use coolkey, which can't read my card? How can I debug this? Final question: Am I correct to assume that my situation does not call for a TPS, TKS, or even a CA? I must not touch the info on these smart cards: Never format, never issue certs, never save, never change. My machines just need to respect a totally external PKI infrastructure: ask for PIN, verify cert against the CA bundle, and start a login session. For any of the things I would need a PKI infrastructure for, I need to make an appointment at a GSA Credentialing Center, then physically show up with two forms of ID in hand. Many thanks for your helpful advice! Bryce -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Mon May 18 17:03:45 2015 From: jmagne at redhat.com (John Magne) Date: Mon, 18 May 2015 13:03:45 -0400 (EDT) Subject: [Pki-users] ESC doesn't recognize smartcard / standalone operation? In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7D6415@001FSN2MPN1-044.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7D6415@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: <546428011.1028616.1431968625777.JavaMail.zimbra@redhat.com> Bryce: I would imagine that the smart card manager relies upon coolkey to recognize cards. As per your other question, I think you are fine. The whole TMS system ESC/TPS is used to provision cards with the coolkey applet. For other types of cards it will do nothing but display some minor information about the token. ----- Original Message ----- > From: "Bryce L Nordgren -FS" > To: pki-users at redhat.com > Sent: Saturday, May 16, 2015 3:03:17 PM > Subject: [Pki-users] ESC doesn't recognize smartcard / standalone operation? > > > > My system is to the point where command line interaction with the smart card > behaves as expected, as long as I use the OpenSC middleware to pam_pkcs11, > and not coolkey. Using pklogin_finder asks for the PIN, verifies the > certificates, and maps the user to a local system account. System details in > previous thread: > https://www.redhat.com/archives/pki-users/2015-April/msg00041.html > > > > My expectation was that the ?smart card manager? should pop up when the card > is inserted. It doesn?t. I can type ?esc? at the command line, and it says > ?No Cards Present? with everything greyed out. Likewise, inserting the smart > card at the login prompt does nothing. There _ is _ an ?./escd? process > running. Is ESC hardwired to use coolkey, which can?t read my card? How can > I debug this? > > > > Final question: Am I correct to assume that my situation does not call for a > TPS, TKS, or even a CA? I must not touch the info on these smart cards: > Never format, never issue certs, never save, never change. My machines just > need to respect a totally external PKI infrastructure: ask for PIN, verify > cert against the CA bundle, and start a login session. For any of the things > I would need a PKI infrastructure for, I need to make an appointment at a > GSA Credentialing Center, then physically show up with two forms of ID in > hand. > > > > Many thanks for your helpful advice! > > Bryce > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From jmagne at redhat.com Mon May 18 17:05:10 2015 From: jmagne at redhat.com (John Magne) Date: Mon, 18 May 2015 13:05:10 -0400 (EDT) Subject: [Pki-users] [Coolkey-devel] PIV-II middleware bug in coolkey In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7D63C6@001FSN2MPN1-044.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7D63C6@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: <995748166.1029909.1431968710449.JavaMail.zimbra@redhat.com> File your bug under coolkey. thanks, jack ----- Original Message ----- > From: "Bryce L Nordgren -FS" > To: coolkey-devel at redhat.com, pki-users at redhat.com > Sent: Saturday, May 16, 2015 1:34:25 PM > Subject: [Coolkey-devel] PIV-II middleware bug in coolkey > > > > Continuation of thread started in: > https://www.redhat.com/archives/pki-users/2015-April/msg00041.html > > > > Synopsis: coolkey misinterprets my USDA LincPass (issued by a GSA > Credentialing Center) as a CAC, then fails. It?s a PIV-II, according to > OpenSC, which doesn?t fail. > > > > Using the OpenSC module with pam-pkcs11, I was able to get pklogin_finder to > validate my certificates and associate my card to a user account via cn > mapper. Using the coolkey module, errors ensued and logs are attached to the > above thread. > > > > The question is: how do I/should I report this bug? Coolkey looks dead. No > svn commits for 4 years. Last mailing list traffic on coolkey-devel was > 2012. Is there anyone on the project? > > > > In the interim, I was also able to locate a standard deck of test cards [1], > both for 30 day loan and for purchase @ $1900. The test deck contains two > ?golden? cards and 22 cards with known problems that the software should > catch. It does not appear I can request an ?extra? card from USDA for > testing. If there?s anyone left to update coolkey, do you think the 30 day > loan (potentially with an extension) is enough time to debug the software, > or at the very least get a start on it? > > > > If the $1900 deck is necessary to add this functionality, it may be possible > to donate or semi-permanently loan a set to the open source project. But I?d > definitely need to understand what the coolkey project?s release and testing > plan is and who would hold the physical assets. > > > > Thanks, > > Bryce > > > > [1] http://www.idmanagement.gov/ficam-testing-program > > > > _______________________________________________ > Coolkey-devel mailing list > Coolkey-devel at redhat.com > https://www.redhat.com/mailman/listinfo/coolkey-devel From bnordgren at fs.fed.us Mon May 18 20:45:28 2015 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Mon, 18 May 2015 20:45:28 +0000 Subject: [Pki-users] [Coolkey-devel] PIV-II middleware bug in coolkey In-Reply-To: <995748166.1029909.1431968710449.JavaMail.zimbra@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7D63C6@001FSN2MPN1-044.001f.mgd2.msft.net> <995748166.1029909.1431968710449.JavaMail.zimbra@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7DA9F9@001FSN2MPN1-046.001f.mgd2.msft.net> Done. > -----Original Message----- > From: John Magne [mailto:jmagne at redhat.com] > Sent: Monday, May 18, 2015 11:05 AM > To: Nordgren, Bryce L -FS > Cc: coolkey-devel at redhat.com; pki-users at redhat.com > Subject: Re: [Coolkey-devel] PIV-II middleware bug in coolkey > > File your bug under coolkey. > > thanks, > jack > > > ----- Original Message ----- > > From: "Bryce L Nordgren -FS" > > To: coolkey-devel at redhat.com, pki-users at redhat.com > > Sent: Saturday, May 16, 2015 1:34:25 PM > > Subject: [Coolkey-devel] PIV-II middleware bug in coolkey > > > > > > > > Continuation of thread started in: > > https://www.redhat.com/archives/pki-users/2015-April/msg00041.html > > > > > > > > Synopsis: coolkey misinterprets my USDA LincPass (issued by a GSA > > Credentialing Center) as a CAC, then fails. It?s a PIV-II, according > > to OpenSC, which doesn?t fail. > > > > > > > > Using the OpenSC module with pam-pkcs11, I was able to get > > pklogin_finder to validate my certificates and associate my card to a > > user account via cn mapper. Using the coolkey module, errors ensued > > and logs are attached to the above thread. > > > > > > > > The question is: how do I/should I report this bug? Coolkey looks > > dead. No svn commits for 4 years. Last mailing list traffic on > > coolkey-devel was 2012. Is there anyone on the project? > > > > > > > > In the interim, I was also able to locate a standard deck of test > > cards [1], both for 30 day loan and for purchase @ $1900. The test > > deck contains two ?golden? cards and 22 cards with known problems that > > the software should catch. It does not appear I can request an ?extra? > > card from USDA for testing. If there?s anyone left to update coolkey, > > do you think the 30 day loan (potentially with an extension) is enough > > time to debug the software, or at the very least get a start on it? > > > > > > > > If the $1900 deck is necessary to add this functionality, it may be > > possible to donate or semi-permanently loan a set to the open source > > project. But I?d definitely need to understand what the coolkey > > project?s release and testing plan is and who would hold the physical > assets. > > > > > > > > Thanks, > > > > Bryce > > > > > > > > [1] http://www.idmanagement.gov/ficam-testing-program > > > > > > > > _______________________________________________ > > Coolkey-devel mailing list > > Coolkey-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/coolkey-devel From dsirrine at redhat.com Thu May 21 14:15:06 2015 From: dsirrine at redhat.com (Dave Sirrine) Date: Thu, 21 May 2015 10:15:06 -0400 (EDT) Subject: [Pki-users] ESC doesn't recognize smartcard / standalone operation? In-Reply-To: <546428011.1028616.1431968625777.JavaMail.zimbra@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7D6415@001FSN2MPN1-044.001f.mgd2.msft.net> <546428011.1028616.1431968625777.JavaMail.zimbra@redhat.com> Message-ID: <682772593.1850957.1432217706434.JavaMail.zimbra@redhat.com> Bryce, To piggyback on what Jack was saying, I'd like to confirm your usecase that you're only using the cards to authenticate into a system. Can you confirm the cards you're using and what OS you're trying to enable? This is a pretty solid doc on how to do this: https://docs.fedoraproject.org/en-US/Fedora//html/Security_Guide/sect-Security_Guide-Single_Sign_on_SSO-Getting_Started_with_your_new_Smart_Card.html I would recommend looking more deeply into pam_pkcs11 as it provides several mechanisms by which you can authenticate, so picking the right one for you may take some reading. Happy to help! ----- Original Message ----- > From: "John Magne" > To: "Bryce L Nordgren -FS" > Cc: pki-users at redhat.com > Sent: Monday, May 18, 2015 1:03:45 PM > Subject: Re: [Pki-users] ESC doesn't recognize smartcard / standalone > operation? > Bryce: > I would imagine that the smart card manager relies upon coolkey to recognize > cards. > As per your other question, I think you are fine. The whole TMS system > ESC/TPS is used to > provision cards with the coolkey applet. For other types of cards it will do > nothing but > display some minor information about the token. > ----- Original Message ----- > > From: "Bryce L Nordgren -FS" > > To: pki-users at redhat.com > > Sent: Saturday, May 16, 2015 3:03:17 PM > > Subject: [Pki-users] ESC doesn't recognize smartcard / standalone > > operation? > > > > > > > > My system is to the point where command line interaction with the smart > > card > > behaves as expected, as long as I use the OpenSC middleware to pam_pkcs11, > > and not coolkey. Using pklogin_finder asks for the PIN, verifies the > > certificates, and maps the user to a local system account. System details > > in > > previous thread: > > https://www.redhat.com/archives/pki-users/2015-April/msg00041.html > > > > > > > > My expectation was that the ?smart card manager? should pop up when the > > card > > is inserted. It doesn?t. I can type ?esc? at the command line, and it says > > ?No Cards Present? with everything greyed out. Likewise, inserting the > > smart > > card at the login prompt does nothing. There _ is _ an ?./escd? process > > running. Is ESC hardwired to use coolkey, which can?t read my card? How can > > I debug this? > > > > > > > > Final question: Am I correct to assume that my situation does not call for > > a > > TPS, TKS, or even a CA? I must not touch the info on these smart cards: > > Never format, never issue certs, never save, never change. My machines just > > need to respect a totally external PKI infrastructure: ask for PIN, verify > > cert against the CA bundle, and start a login session. For any of the > > things > > I would need a PKI infrastructure for, I need to make an appointment at a > > GSA Credentialing Center, then physically show up with two forms of ID in > > hand. > > > > > > > > Many thanks for your helpful advice! > > > > Bryce > > > > _______________________________________________ > > Pki-users mailing list > > Pki-users at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-users > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Thu May 21 15:46:41 2015 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Thu, 21 May 2015 15:46:41 +0000 Subject: [Pki-users] ESC doesn't recognize smartcard / standalone operation? In-Reply-To: <682772593.1850957.1432217706434.JavaMail.zimbra@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7D6415@001FSN2MPN1-044.001f.mgd2.msft.net> <546428011.1028616.1431968625777.JavaMail.zimbra@redhat.com> <682772593.1850957.1432217706434.JavaMail.zimbra@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7DE4B8@001FSN2MPN1-046.001f.mgd2.msft.net> Hi Dave, The use case is a ?collaboration environment.? Some small subset of USDA?s tens of thousands of employees are engaged in research with external parties. The collaboration environment, being exposed to external actors, does not have contact with the government Active Directory server, and likely never will. This external environment must support registered Win/Linux/Mac clients, as well as connection to registered devices from unregistered devices. The overarching goal is ?convenience-oriented? in that we are trying to avoid creating new credentials/passwords for users of the environment to (mis)manage and remember(forget). Existing PIV credentials are envisioned to cover the fraction of users who are employees, due largely to the fact that connectivity to AD is not necessary. External parties will likely be issued a username/password. My test system is Fedora 21. The document you reference is how I started. The document?s reliance on coolkey exposed the fact that the Coolkey middleware does not read the standard issue USDA LincPass PIV smartcard correctly. Replacing coolkey with OpenSC middleware allows me to inspect certificates. Nominal playing with pam_pkcs11 has ?smart-card enabled? the ?sudo? function on my test box. I do not currently understand how pam_pkcs11 relates to a graphical login manager. I was under the impression that ESC supplied the GUI login component, and ESC apparently is hardwired to Coolkey. I am currently setting up an MIT Kerberos server with PKINIT to get a TGT based on a PIV authentication for basic Kerberos SSO. As I understand it, pam_pkcs11 can be instructed to leverage such an infrastructure. However, as I understand it, a mixed Win/Linux environment is best served with Active Directory hosting users and Win clients, FreeIPA/IdM hosting Linux clients with FreeIPA/IdM set up to trust AD. If this is the case, it is likely PIV authentication will need to be directed against a separate, disconnected ?collaboration? AD instance, and I will need to repeat the MIT Kerberos effort with this AD. I haven?t really heard much about special purpose Mac domain controllers. I assume they?re Linuxy enough that FreeIPA/IdM is more appropriate than AD. Criticisms are welcome. I?ve really never done anything like this before and I?ve wished more than once that our professionals would step up and address this need. Seems unlikely. The obvious shortcoming of my plan is that employees either do not have passwords at all, or they have another password to manage, as syncing the collaboration AD with the corporate AD is just as out of the question as exposing AD. Bryce From: Dave Sirrine [mailto:dsirrine at redhat.com] Sent: Thursday, May 21, 2015 8:15 AM To: John Magne Cc: Nordgren, Bryce L -FS; pki-users at redhat.com Subject: Re: [Pki-users] ESC doesn't recognize smartcard / standalone operation? Bryce, To piggyback on what Jack was saying, I'd like to confirm your usecase that you're only using the cards to authenticate into a system. Can you confirm the cards you're using and what OS you're trying to enable? This is a pretty solid doc on how to do this: https://docs.fedoraproject.org/en-US/Fedora//html/Security_Guide/sect-Security_Guide-Single_Sign_on_SSO-Getting_Started_with_your_new_Smart_Card.html I would recommend looking more deeply into pam_pkcs11 as it provides several mechanisms by which you can authenticate, so picking the right one for you may take some reading. Happy to help! ________________________________ From: "John Magne" > To: "Bryce L Nordgren -FS" > Cc: pki-users at redhat.com Sent: Monday, May 18, 2015 1:03:45 PM Subject: Re: [Pki-users] ESC doesn't recognize smartcard / standalone operation? Bryce: I would imagine that the smart card manager relies upon coolkey to recognize cards. As per your other question, I think you are fine. The whole TMS system ESC/TPS is used to provision cards with the coolkey applet. For other types of cards it will do nothing but display some minor information about the token. ----- Original Message ----- > From: "Bryce L Nordgren -FS" > > To: pki-users at redhat.com > Sent: Saturday, May 16, 2015 3:03:17 PM > Subject: [Pki-users] ESC doesn't recognize smartcard / standalone operation? > > > > My system is to the point where command line interaction with the smart card > behaves as expected, as long as I use the OpenSC middleware to pam_pkcs11, > and not coolkey. Using pklogin_finder asks for the PIN, verifies the > certificates, and maps the user to a local system account. System details in > previous thread: > https://www.redhat.com/archives/pki-users/2015-April/msg00041.html > > > > My expectation was that the ?smart card manager? should pop up when the card > is inserted. It doesn?t. I can type ?esc? at the command line, and it says > ?No Cards Present? with everything greyed out. Likewise, inserting the smart > card at the login prompt does nothing. There _ is _ an ?./escd? process > running. Is ESC hardwired to use coolkey, which can?t read my card? How can > I debug this? > > > > Final question: Am I correct to assume that my situation does not call for a > TPS, TKS, or even a CA? I must not touch the info on these smart cards: > Never format, never issue certs, never save, never change. My machines just > need to respect a totally external PKI infrastructure: ask for PIN, verify > cert against the CA bundle, and start a login session. For any of the things > I would need a PKI infrastructure for, I need to make an appointment at a > GSA Credentialing Center, then physically show up with two forms of ID in > hand. > > > > Many thanks for your helpful advice! > > Bryce > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrniranjan at redhat.com Fri May 15 05:42:01 2015 From: mrniranjan at redhat.com (Niranjan M.R) Date: Fri, 15 May 2015 11:12:01 +0530 Subject: [Pki-users] Can I change the CN = CA Signing Certificate to something else? In-Reply-To: References: Message-ID: <55558729.8020500@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/15/2015 10:59 AM, Ben Peck wrote: > I'm running Fedora 21 with Dogtag 10.2.1-3. My CA's Certificate was given "CA Signing Certificate" as its CN, and I'm wondering how it got that way > and it might be customized on install. > > Running pkispawn interactively definitely didn't give me an opportunity to supply a name, and looking over the config file I could customize also > doesn't seem to provide an opportunity to customize this: > > Dogtag 9 gave the opportunity to customize this as part of the initial setup - where is this done in version 10? You could pass an inf file to pkispawn pkispawn -s CA -f /tmp/ca_instance.inf -v In the inf file you could customize. Sample inf file: http://fpaste.org/222174/43166849/ > > thanks, > Ben > > > |pki_admin_email=caadmin at example.com > pki_admin_name=caadmin > pki_admin_nickname=caadmin > pki_admin_password=Secret123 > pki_admin_uid=caadmin > pki_backup_keys=True > pki_backup_password=Secret123 > pki_client_database_password=Secret123 > pki_client_database_purge=False > pki_client_pkcs12_password=Secret123 > pki_ds_base_dn=dc=ca,dc=example,dc=com > pki_ds_database=ca > pki_ds_password=Secret123 > pki_security_domain_name=EXAMPLE > pki_token_password=Secret123| > > > > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > - -- Niranjan irc: mrniranjan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iKYEARECAGYFAlVVhylfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEY3OTE3QTg3ODE0RkVCQ0YyNjgyOTRENjJF RURDNTVGNjA0N0M3QzcACgkQLu3FX2BHx8cVBgCfR0V7nHJSeUOQR2VdTcehXISQ piEAoJwjWh72sSwSZ2L2o0bq0pU4IJr4 =SjGX -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x6047C7C7.asc Type: application/pgp-keys Size: 1893 bytes Desc: not available URL: