From rafal.kaminski at blstream.com Mon Mar 1 14:34:51 2010 From: rafal.kaminski at blstream.com (=?UTF-8?B?UmFmYcWCIEthbWnFhHNraQ==?=) Date: Mon, 01 Mar 2010 15:34:51 +0100 Subject: [Pki-users] yum install pki-ca - and problem :( Message-ID: <4B8BD08B.1000207@blstream.com> Hi all, I install dogtag two months ago, and now I repeat that move, but ... When I use: yum install pki-ca I see: Installing : pki-common-1.3.0-7.fc11.noarch 156/158 Installing : hal-info-20090414-1.fc11.noarch 157/158 Adding default PKI group "pkiuser" to /etc/group. Adding default PKI user "pkiuser" to /etc/passwd. useradd: warning: the home directory already exists. Not copying any file from skel directory into it. Installing : pki-ca-1.2.0-4.fc11.noarch 158/158 PKI instance creation Utility ... [2010-02-02 04:39:15] [error] create_symbolic_link(): illegal destination path => /usr/share/java/ca.jar. Error detected would you like to clean up /var/lib/pki-ca (Y/N)? Error detected would you like to clean up /var/lib/pki-ca (Y/N)? Can sombody tell me why? BR, Rafal Kaminski From ehimawan at gmail.com Tue Mar 2 04:17:31 2010 From: ehimawan at gmail.com (Erwin Himawan) Date: Mon, 1 Mar 2010 22:17:31 -0600 Subject: [Pki-users] yum install pki-ca - and problem :( In-Reply-To: <4B8BD08B.1000207@blstream.com> References: <4B8BD08B.1000207@blstream.com> Message-ID: <4936964742A548B4B89F4892B91C5947@d8400> I experienced the same install issue. Here is what you have to do. When you run your "yum install pki-ca" in the first place, observe the version of pki-related dependencies; i.e. pkiconsole, pki-ca, dogtag* I believe when you do this yum install, yum accidently picks up 1.3.0 version, except the pki-ca. In order to confirm this mixed version, you can do "yum list | grep pki | grep installed" This will list the version and pki-related packages and notice the mixed of 1.2.0 and 1.3.0 versions. To ensure version consistency, you can either all 1.2.0 version or 1.30 version. I personally keep the 1.3.0 version. To keep the 1.3.0 version, do "yum erase pki-ca" and other pki and dogtag packages belonging to 1.2.0 version. After you erase all the 1.2.0 version, do "yum list | grep pki | grep installed" again to ensure no 1.2.0 version package is installed. Also, make sure that all dependencies have also been installed; I.e. the java, tomcat, etc. If those dependencies are not installed yet, I recommend you to install those packages separately. Assuming the remainder of the pakcages are pki related and dogtag related, you can use the following command to install the 1.3.0 version. Use "yum install pki-ca --enablerepo=updates-testing". This command will pick up the 1.30 versions for pki and dogtag related packages. Thanks to Kashyap for showing this, reff: https://www.redhat.com/archives/pki-users/2010-January/msg00016.html When you do this, you might encounter error for which you want to check your /etc/yum.repos.d/fedora-updates-testing.repo In this file make sure to uncomment the "base...." and comment the "mirrorlist....." for each section. After you successfully install the pki-ca packages, you can proceed with pkicreate to create the ca instance. Just type the pkicreate and it spits out the required parameters. I sue default value. Let me know if you need more help. By the way, I have not created pki-ra yet; that's the next thing on my list. By the way, when you configured your ca, make sure your directory server process is running; check using "ps -ef | grep dirsrv" (if you install your directory server locally). Or, use /etc/init status | start | stop | restart. Erwin -------------------------------------------------- From: "Rafal Kaminski" Sent: Monday, March 01, 2010 8:34 AM To: Subject: [Pki-users] yum install pki-ca - and problem :( > Hi all, > > I install dogtag two months ago, and now I repeat that move, but ... > > When I use: yum install pki-ca > > I see: > > Installing : pki-common-1.3.0-7.fc11.noarch > 156/158 > Installing : hal-info-20090414-1.fc11.noarch > 157/158 > Adding default PKI group "pkiuser" to /etc/group. > Adding default PKI user "pkiuser" to /etc/passwd. > useradd: warning: the home directory already exists. > Not copying any file from skel directory into it. > Installing : pki-ca-1.2.0-4.fc11.noarch > 158/158 > PKI instance creation Utility ... > > [2010-02-02 04:39:15] [error] create_symbolic_link(): illegal destination > path => /usr/share/java/ca.jar. > > Error detected would you like to clean up /var/lib/pki-ca (Y/N)? > Error detected would you like to clean up /var/lib/pki-ca (Y/N)? > > Can sombody tell me why? > > BR, > > Rafal Kaminski > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From johannes.russek at io-consulting.net Tue Mar 2 10:45:21 2010 From: johannes.russek at io-consulting.net (jr) Date: Tue, 02 Mar 2010 11:45:21 +0100 Subject: [Pki-users] upgrading/updating dogtag Message-ID: <1267526721.18295.2.camel@dell-jr.intern.win-rar.com> Hello List, I have a dogtag 1.0.0 installation running and i was thinking about updating it to the current 1.3.0. However, i was unable to find any documents on how one would update dogtag and keep all the configuration settings. Is there some sort of best-practive in updating dogtag? Thanks, Johannes From rafal.kaminski at blstream.com Tue Mar 2 11:40:40 2010 From: rafal.kaminski at blstream.com (=?UTF-8?B?UmFmYcWCIEthbWnFhHNraQ==?=) Date: Tue, 02 Mar 2010 12:40:40 +0100 Subject: [Pki-users] yum install pki-ca - and problem :( In-Reply-To: <4936964742A548B4B89F4892B91C5947@d8400> References: <4B8BD08B.1000207@blstream.com> <4936964742A548B4B89F4892B91C5947@d8400> Message-ID: <4B8CF938.9040100@blstream.com> Hi, It's WORKS!!! Thanks. > When you do this, you might encounter error for which you want to check > your /etc/yum.repos.d/fedora-updates-testing.repo > In this file make sure to uncomment the "base...." and comment the > "mirrorlist....." for each section. I didn't have that error :) > After you successfully install the pki-ca packages, you can proceed with > pkicreate to create the ca instance. Just type the pkicreate and it > spits out the required parameters. I sue default value. I could create pki-ca. > Let me know if you need more help. By the way, I have not created pki-ra > yet; that's the next thing on my list. I see only one mistake: new package pki-ca set /etc/init.d/pki-cad scripts :) CAD! :) Once again thanks a lot :)!!! Br, Rafal Kaminski From alee at redhat.com Tue Mar 2 15:11:04 2010 From: alee at redhat.com (Ade Lee) Date: Tue, 02 Mar 2010 10:11:04 -0500 Subject: [Pki-users] yum install pki-ca - and problem :( In-Reply-To: <4B8CF938.9040100@blstream.com> References: <4B8BD08B.1000207@blstream.com> <4936964742A548B4B89F4892B91C5947@d8400> <4B8CF938.9040100@blstream.com> Message-ID: <1267542664.20012.166.camel@localhost.localdomain> Rafal, The pki-cad script is part of a new feature that has been added to dogtag. The pki-cad script is used to start all CA instances on a box. To start all instances, service pki-cad start To start a particular instance foo: service pki-cad start foo There will be similar scripts for pki-rad, pki-ocspd etc. Ade On Tue, 2010-03-02 at 12:40 +0100, Rafa? Kami?ski wrote: > Hi, > > It's WORKS!!! Thanks. > > > When you do this, you might encounter error for which you want to check > > your /etc/yum.repos.d/fedora-updates-testing.repo > > In this file make sure to uncomment the "base...." and comment the > > "mirrorlist....." for each section. > > I didn't have that error :) > > > After you successfully install the pki-ca packages, you can proceed with > > pkicreate to create the ca instance. Just type the pkicreate and it > > spits out the required parameters. I sue default value. > > I could create pki-ca. > > > Let me know if you need more help. By the way, I have not created pki-ra > > yet; that's the next thing on my list. > > I see only one mistake: new package pki-ca set /etc/init.d/pki-cad > scripts :) CAD! :) > > Once again thanks a lot :)!!! > > Br, > > Rafal Kaminski > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From ehimawan at gmail.com Fri Mar 5 02:44:44 2010 From: ehimawan at gmail.com (Erwin Himawan) Date: Thu, 4 Mar 2010 20:44:44 -0600 Subject: [Pki-users] Re-instating Revoked Certificate Message-ID: <2b8d35db1003041844yee7d057h87a5bd9be04f0c8f@mail.gmail.com> Hi All, I noticed in the redhat certificate administration guide for reasons of revoking certificate. "The certificate is on hold pending further action. It is treated as revoked but may be taken off hold in the future." The way I understood the above quoted statement; I can put a certificate into revocation list and at later time, re-instate the certificate. My question is, how do I re-instate a revoked certificate which revocation reason is under the above revocation-category. Thanks, Erwin -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Fri Mar 5 03:29:04 2010 From: cfu at redhat.com (Christina Fu) Date: Thu, 04 Mar 2010 19:29:04 -0800 Subject: [Pki-users] Re-instating Revoked Certificate In-Reply-To: <2b8d35db1003041844yee7d057h87a5bd9be04f0c8f@mail.gmail.com> References: <2b8d35db1003041844yee7d057h87a5bd9be04f0c8f@mail.gmail.com> Message-ID: <4B907A80.5030004@redhat.com> For the revoked cert with reson "Certificate is on hold" you should see an "Off Hold" button right below "Details" when you list (or search) the certificate. Click on the "Off Hold" button then your cert will be taken off hold. I hope we have it in the doc somewhere. Christina Erwin Himawan wrote: > Hi All, > > I noticed in the redhat certificate administration guide for reasons > of revoking certificate. > > "The certificate is on hold pending further action. It is treated as > revoked but may be taken off hold in the future." > > The way I understood the above quoted statement; I can put a > certificate into revocation list and at later time, re-instate the > certificate. > > My question is, how do I re-instate a revoked certificate which > revocation reason is under the above revocation-category. > > > Thanks, > Erwin > ------------------------------------------------------------------------ > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > From ehimawan at gmail.com Fri Mar 5 18:43:26 2010 From: ehimawan at gmail.com (Erwin Himawan) Date: Fri, 5 Mar 2010 12:43:26 -0600 Subject: [Pki-users] Re-instating Revoked Certificate In-Reply-To: <4B907A80.5030004@redhat.com> References: <2b8d35db1003041844yee7d057h87a5bd9be04f0c8f@mail.gmail.com> <4B907A80.5030004@redhat.com> Message-ID: <2b8d35db1003051043r76fe7acl80b0d6637fbde88a@mail.gmail.com> Christina, Thanks. I can reinstate the on-hold certificate. It is not obvious in the documentation (section 6.1.2). It would be helpful to include some explanations on how to reinstate on-hold certificates. Erwin On Thu, Mar 4, 2010 at 9:29 PM, Christina Fu wrote: > For the revoked cert with reson "Certificate is on hold" you should see an > "Off Hold" button right below "Details" when you list (or search) the > certificate. Click on the "Off Hold" button then your cert will be taken > off hold. > > I hope we have it in the doc somewhere. > > Christina > > Erwin Himawan wrote: > >> Hi All, >> >> I noticed in the redhat certificate administration guide for reasons of >> revoking certificate. >> >> "The certificate is on hold pending further action. It is treated as >> revoked but may be taken off hold in the future." >> >> The way I understood the above quoted statement; I can put a certificate >> into revocation list and at later time, re-instate the certificate. >> >> My question is, how do I re-instate a revoked certificate which revocation >> reason is under the above revocation-category. >> >> >> Thanks, >> Erwin >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 rashmeepawar at gmail.com Mon Mar 8 04:56:58 2010 From: rashmeepawar at gmail.com (Rashmi) Date: Mon, 8 Mar 2010 10:26:58 +0530 Subject: [Pki-users] Dear Pki-Users, If you can't find in google, try JUSTDIAL.COM Message-ID: <18c507e43573240959fb10672ed2542f@192.168.1.23> Dear Pki-Users,I strongly recommend this website www.justdial.com. It's a world class local search service & I've always found anything I've ever wanted.You can find info on any company, product, or service in over 240 cities in India.You can also call them up 24x7, on phone (69999999), a local call in 240 Indian cities.Ask for anything, you'll get the info on the phone and/or by SMS within 30 secs, and this service is at no cost!For a change, it's an original Indian idea and an Indian company with world class service, and with a vision to spread all over the world.Be a proud Indian and forward this to every Indian you know.Best Wishes,RashmiClick Here to unsubscribe. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ehimawan at gmail.com Tue Mar 9 00:06:52 2010 From: ehimawan at gmail.com (Erwin Himawan) Date: Mon, 8 Mar 2010 18:06:52 -0600 Subject: [Pki-users] Unable to connect to Secure Admin Port In-Reply-To: <4B867C14.9000901@dmbr.vib-UGent.be> References: <4B867C14.9000901@dmbr.vib-UGent.be> Message-ID: Hi Didier, I am not familiar with Red Hat. I assumed Red Hat has some similarities with Fedora 11. If you do not mind, can you provide me with the last 20 lines of your /var/log/pki-ca-install.... file? (Assuming you are using default file location). One other useful log is your directory server installation log. Do you successfully configure your directory server? Could you also make sure that you do not mix up your dogtag CS versions. Another pointer, when you run your pkicreate, make sure that your fedora directory serve is running. (/etc/init.d/dirsrv status) If the directory server is not running, you want to start it first; /etc/init.d/dirsrv start. Erwin -------------------------------------------------- From: "Didier Moens" Sent: Thursday, February 25, 2010 7:33 AM To: Subject: [Pki-users] Unable to connect to Secure Admin Port > Dear all, > > > For the past few days, I've been struggling trying to set up our > dogtag-based PKI. Unfortunately, I am unable to access the Secure Admin > Port / Configuration Wizard (https://...:9445/...), probably due to > Tomcat failing to open SSL sockets. > > > - Configuration : clean RHEL5u4 ; > - Installed pki-ca-1.3.0 (tried 1.3.2 too) from EPEL, with all its > dependencies (except jss-4.2.6, which is installed from EPEL-testing) ; > - tomcatjss-1.2.0 is installed as a dependency too. > > There is no "tomcat5-native" package installed, and LANG is set to C, > all to no avail. > > > > After manually creating user 'pkiuser' (pki-setup 1.3.1 does not > automatically create this user) , "pkicreate" (with parameters from the > root CA example) yields the following errors in > /var/log/pki-ca/catalina.out : > > > ... > org.apache.coyote.http11.Http11BaseProtocol init > SEVERE: Error initializing socket factory > java.lang.ClassNotFoundException: Error loading SSL Implementation > org.apache.tomcat.util.net.jss.JSSImplementation > :java.lang.ClassNotFoundException: > org.apache.tomcat.util.net.jss.JSSImplementation > at > org.apache.tomcat.util.net.SSLImplementation.getInstance(SSLImplementation.java:79) > at > org.apache.coyote.http11.Http11BaseProtocol.checkSocketFactory(Http11BaseProtocol.java:731) > at > org.apache.coyote.http11.Http11BaseProtocol.init(Http11BaseProtocol.java:121) > at > org.apache.catalina.connector.Connector.initialize(Connector.java:1017) > at > org.apache.catalina.core.StandardService.initialize(StandardService.java:578) > at > org.apache.catalina.core.StandardServer.initialize(StandardServer.java:782) > at org.apache.catalina.startup.Catalina.load(Catalina.java:504) > at org.apache.catalina.startup.Catalina.load(Catalina.java:524) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:267) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) > Feb 25, 2010 1:52:12 PM org.apache.catalina.startup.Catalina load > SEVERE: Catalina.start > LifecycleException: Protocol handler initialization failed: > java.lang.ClassNotFoundException: Error loading SSL Implementation > org.apache.tomcat.util.net.jss.JSSImplementation > :java.lang.ClassNotFoundException: > org.apache.tomcat.util.net.jss.JSSImplementation > at > org.apache.catalina.connector.Connector.initialize(Connector.java:1019) > at > org.apache.catalina.core.StandardService.initialize(StandardService.java:578) > at > org.apache.catalina.core.StandardServer.initialize(StandardServer.java:782) > at org.apache.catalina.startup.Catalina.load(Catalina.java:504) > at org.apache.catalina.startup.Catalina.load(Catalina.java:524) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:267) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) > ... > > > Strangely enough, connections are set up on e.g. the Agent Secure Port > (9443), but neither on the EE Secure Port (9444) : > > # lsof |grep pkiuser |grep TCP > java 28349 pkiuser 71u IPv6 > 1445890 TCP *:9180 (LISTEN) > java 28349 pkiuser 76u IPv6 > 1445899 TCP *:9443 (LISTEN) > java 28349 pkiuser 77u IPv6 > 1445900 TCP localhost.localdomain:9701 (LISTEN) > > > Both '/etc/pki-ca/tomcat5.conf' and '/etc/pki-ca/server.xml' look valid > (disclaimer: I am a Tomcat novice). > > > > Stracing (-e trace=file) the pki-cad process yields nothing useful, > except for the fact that tomcatjss.jar seems to be nowhere accessed. > > When manually adding ":/usr/share/java/tomcatjss.jar" to the CLASSPATH > variable in '/usr/bin/dtomcat5-pki-ca', Tomcat throws these exceptions > in catalina.out : > > ... > org.apache.coyote.http11.Http11BaseProtocol init > INFO: Initializing Coyote HTTP/1.1 on http-9180 > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:267) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) > Caused by: java.lang.NoClassDefFoundError: > org/apache/tomcat/util/net/SSLImplementation > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:632) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:277) > at java.net.URLClassLoader.access$000(URLClassLoader.java:73) > at java.net.URLClassLoader$1.run(URLClassLoader.java:212) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:205) > at java.lang.ClassLoader.loadClass(ClassLoader.java:319) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) > at java.lang.ClassLoader.loadClass(ClassLoader.java:312) > at java.lang.ClassLoader.loadClass(ClassLoader.java:312) > at java.lang.ClassLoader.loadClass(ClassLoader.java:264) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:332) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:186) > at > org.apache.tomcat.util.net.SSLImplementation.getInstance(SSLImplementation.java:73) > at > org.apache.coyote.http11.Http11BaseProtocol.checkSocketFactory(Http11BaseProtocol.java:731) > at > org.apache.coyote.http11.Http11BaseProtocol.init(Http11BaseProtocol.java:121) > at > org.apache.catalina.connector.Connector.initialize(Connector.java:1017) > at > org.apache.catalina.core.StandardService.initialize(StandardService.java:578) > at > org.apache.catalina.core.StandardServer.initialize(StandardServer.java:782) > at org.apache.catalina.startup.Catalina.load(Catalina.java:504) > at org.apache.catalina.startup.Catalina.load(Catalina.java:524) > ... 6 more > Caused by: java.lang.ClassNotFoundException: > org.apache.tomcat.util.net.SSLImplementation > at java.net.URLClassLoader$1.run(URLClassLoader.java:217) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:205) > at java.lang.ClassLoader.loadClass(ClassLoader.java:319) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) > at java.lang.ClassLoader.loadClass(ClassLoader.java:264) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:332) > ... 30 more > > > > As a last resort, I created a tomcat keystore too, but as this is > nowhere mentioned in the docs, I guess this is way off. > > > I would be grateful for any clue whatsoever. > > > Best regards, > Didier > > -- > =================================================================== > Didier Moens IT services > Department for Molecular Biomedical Research (DMBR) > VIB - Ghent University > Fiers-Schell-Van Montagu Research Building > Technologiepark 927 , B-9052 Zwijnaarde , Belgium > tel ++32(9)3313605 fax ++32(9)3313609 > mailto:Didier.Moens at dmbr.vib-UGent.be http://www.dmbr.UGent.be > =================================================================== > This message represents the official view of the voices in my head. > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From Shanthi.Thomas at motorola.com Tue Mar 9 17:18:48 2010 From: Shanthi.Thomas at motorola.com (Thomas Shanthi-LST016) Date: Tue, 9 Mar 2010 12:18:48 -0500 Subject: [Pki-users] CA protocol support References: <4910A5141972A44EBD0A3E74AE696BB0A99D3329@de01exm71.ds.mot.com> Message-ID: Hi, I've recently started using the dogtag CA. As I understand the CA supports CMC and SCEP. Assuming this is correct, can end-entities use CMC or SCEP protocol to directly access the CA or RA or is only the web-interface supported? In other words, is there API support for the CA/RA? thanks, Shanthi -------------- next part -------------- An HTML attachment was scrubbed... URL: From msauton at redhat.com Tue Mar 9 17:46:14 2010 From: msauton at redhat.com (Marc Sauton) Date: Tue, 09 Mar 2010 09:46:14 -0800 Subject: [Pki-users] CA protocol support In-Reply-To: References: <4910A5141972A44EBD0A3E74AE696BB0A99D3329@de01exm71.ds.mot.com> Message-ID: <4B968966.5070007@redhat.com> On 03/09/2010 09:18 AM, Thomas Shanthi-LST016 wrote: > Hi, > I've recently started using the dogtag CA. As I understand the CA > supports CMC and SCEP. Assuming this is correct, can end-entities use > CMC or SCEP protocol to directly access the CA or RA or is only the > web-interface supported? In other words, is there API support for the > CA/RA? > thanks, > Shanthi > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > No need of the WEB interface for using CMC and SCEP protocols, it goes through either a CA or a RA instance, see the admin, deployment guides at http://www.redhat.com/docs/manuals/cert-system/ Also: http://pki.fedoraproject.org/wiki/PKI_SCEP_Support_In_Certificate_System For CMC, see command line guide and admin guide (like chapter "6.2. CMC Revocation", and "9.3. Setting up CMC Enrollment" if you already have a request) M. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6650 bytes Desc: S/MIME Cryptographic Signature URL: From ehimawan at gmail.com Wed Mar 10 02:06:55 2010 From: ehimawan at gmail.com (Erwin Himawan) Date: Tue, 9 Mar 2010 20:06:55 -0600 Subject: [Pki-users] File Publishing Message-ID: <2b8d35db1003091806l5d3b1703l1c904c17a7674f39@mail.gmail.com> Hi, I am in the process of understanding and evaluating the DCS features. I come across the publishing feature whereby DCS can publish certificates and/or CRL to a flat file. I followed RH CS Admin Guide 8.0, in particular, on section 8.2.1, 8.2.4 (Creating Rules). However, when I was testing the file-publication configuration, following direction on section 8.5, I did not see the expected certificate files and crl files. Any idea as how to troubleshoot from here? Thanks, Erwin -------------- next part -------------- An HTML attachment was scrubbed... URL: From Didier.Moens at dmbr.vib-UGent.be Fri Mar 12 16:21:57 2010 From: Didier.Moens at dmbr.vib-UGent.be (Didier Moens) Date: Fri, 12 Mar 2010 17:21:57 +0100 Subject: [Pki-users] Unable to connect to Secure Admin Port In-Reply-To: References: <4B867C14.9000901@dmbr.vib-UGent.be> Message-ID: <4B9A6A25.8020905@dmbr.vib-UGent.be> Dear Erwin, Your reply is much appreciated ; apologies for not responding sooner, as I was busy examining some alternative Dogtag paths (without success, see below). On 09/03/10 01:06, Erwin Himawan wrote: > Hi Didier, > > I am not familiar with Red Hat. I assumed Red Hat has some > similarities with Fedora 11. > > If you do not mind, can you provide me with the last 20 lines of your > /var/log/pki-ca-install.... file? (Assuming you are using default file > location). > One other useful log is your directory server installation log. Do > you successfully configure your directory server? > > Could you also make sure that you do not mix up your dogtag CS versions. > > Another pointer, when you run your pkicreate, make sure that your > fedora directory serve is running. > (/etc/init.d/dirsrv status) > > If the directory server is not running, you want to start it first; > /etc/init.d/dirsrv start. Thank you for the advice. 1. Concerning the directory server : at this stage, the DS is not needed, as the connection to the DS is defined in the Installation Wizard (which I am unable to start). 2. I would not mind providing you with logfiles, but I am comparing with a pristine (and successful) installation of Dogtag on a fresh Fedora12 virtual machine, and there are no discernible differences. 3. My next step was to disable the troublesome HTTPS/SSL completely, by removing the https references from /etc/pki-ca/server.xml. While this works for Fedora12 (the Installation Wizard can be reached on http://:9445 instead of https://:9445), I only had partial success with RHEL5 : all server.xml-defined ports are now initialized (9180, 9443, 9444, 9445, 9701), but trying to access the Installation Wizard on http://:9445 now yields an error page (HTTP Status 500 : "The server encountered an unexpected condition which prevented it from fulfilling the request."). Needless to say, the requested file /var/lib/pki-ca/webapps/ca/admin/console/login.vm (from the dogtag-pki-common-ui-1.3.1-1.el5 rpm) is present on the system. (All this was tested with both Sun Java and OpenJDK.) 4. The problem as described in [3.] leads me to believe that DogTag is completely borked on RHEL5/CentOS5. I filed a bugzilla report for the SSL problem (https://bugzilla.redhat.com/show_bug.cgi?id=568787) and I will file another one for problem [3.]. However, there are dependency problems in EPEL5 too (https://bugzilla.redhat.com/show_bug.cgi?id=566342 , comment #16). The bugzilla entries have been filed 14 days ago, unfortunately without any reply from the developers. This, combined with the very low traffic on pki-users (not to mention pki-devel) makes me wonder what the ambitions for DogTag are. Maybe I need to crosspost to centos-devel, but I am not too sure whether they care for packages originating from EPEL ... Best regards, Didier -- =================================================================== Didier Moens IT services Department for Molecular Biomedical Research (DMBR) VIB - Ghent University Fiers-Schell-Van Montagu Research Building Technologiepark 927 , B-9052 Zwijnaarde , Belgium tel ++32(9)3313605 fax ++32(9)3313609 mailto:Didier.Moens at dmbr.vib-UGent.be http://www.dmbr.UGent.be =================================================================== This message represents the official view of the voices in my head. From Shanthi.Thomas at motorola.com Mon Mar 22 16:00:59 2010 From: Shanthi.Thomas at motorola.com (Thomas Shanthi-LST016) Date: Mon, 22 Mar 2010 12:00:59 -0400 Subject: [Pki-users] CErtificate profile validation Message-ID: Hi, Had a question on where certificate profile validation takes places when the user sends the enrollment to the RA and RA sends it to the CA. The authentication selected in the cert profile created at the CA is raCert. In this scenario is it assumed that the RA does all verification of the CSR against the profile? In other words, is it the repsonsibility of the RA to check for fields to be present in the CSR and their current values as specified in the cert profile? Also will the CA add the fields specified in the cert profile that have to be inserted by the CA such as Subject KEy Identifier, Authority Key Identifier, etc. ? thanks, Shanthi Thomas Advanced Technology & Research, Government & Public Safety, Schaumburg, IL, USA desk: 847-576-2499 cell: 224-715-6904 -------------- next part -------------- An HTML attachment was scrubbed... URL: From arshad.noor at strongauth.com Mon Mar 22 16:42:59 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Mon, 22 Mar 2010 08:42:59 -0800 (GMT-08:00) Subject: [Pki-users] CErtificate profile validation In-Reply-To: Message-ID: <4117493.01269276178961.JavaMail.root@gw.noorhome.net> Technically, it can occur at either or both locations. However, from a business and operational point-of-view, most PKIs do the verification at the RA. This is because it allows different RA's to use different policies, procedures and tools to do the key-generation, verification, etc., before sending the verified CSR to the CA for signing. >From an operational point of view, having RAs do the verification allows you to scale a CA to sign more certificates in a given unit of time if it only had to sign certificates and CRLs instead of verifying and signing. Yes, the CA can indeed add all the required constraints/extensions as needed to the certificate based on the profile, before it signs the CSR. Arshad Noor StrongAuth, Inc. ----- Original Message ----- From: "Thomas Shanthi-LST016" To: pki-users at redhat.com Sent: Monday, March 22, 2010 9:00:59 AM (GMT-0800) America/Los_Angeles Subject: [Pki-users] CErtificate profile validation _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users From Shanthi.Thomas at motorola.com Mon Mar 22 16:48:28 2010 From: Shanthi.Thomas at motorola.com (Thomas Shanthi-LST016) Date: Mon, 22 Mar 2010 12:48:28 -0400 Subject: [Pki-users] CErtificate profile validation In-Reply-To: <4117493.01269276178961.JavaMail.root@gw.noorhome.net> References: <4117493.01269276178961.JavaMail.root@gw.noorhome.net> Message-ID: Thanks, Arshad. Is there some way to enforce the CA to cross-check the CSR against the profile when the RA is also present? Or is this automatically enabled? I must have missed something when I set the cert preofile... When I tried this, it seemed as if the CA was not verifying correctness of the issued certificate against the cert profile. It seemed to be just adding its signature. Also it added the Authority Key Indentifier but not the subject key identifier (as per RFC 5280 it looks the CA adds this field) - though both were mentioned in the profile. >>-----Original Message----- >>From: Arshad Noor [mailto:arshad.noor at strongauth.com] >>Sent: Monday, March 22, 2010 11:43 AM >>To: Thomas Shanthi-LST016 >>Cc: pki-users at redhat.com >>Subject: Re: [Pki-users] CErtificate profile validation >> >>Technically, it can occur at either or both locations. >>However, from a business and operational point-of-view, most >>PKIs do the verification at the RA. This is because it >>allows different RA's to use different policies, procedures >>and tools to do the key-generation, verification, etc., >>before sending the verified CSR to the CA for signing. >> >>From an operational point of view, having RAs do the >>verification allows you to scale a CA to sign more >>certificates in a given unit of time if it only had to sign >>certificates and CRLs instead of verifying and signing. >> >>Yes, the CA can indeed add all the required >>constraints/extensions as needed to the certificate based on >>the profile, before it signs the CSR. >> >>Arshad Noor >>StrongAuth, Inc. >> >>----- Original Message ----- >>From: "Thomas Shanthi-LST016" >>To: pki-users at redhat.com >>Sent: Monday, March 22, 2010 9:00:59 AM (GMT-0800) America/Los_Angeles >>Subject: [Pki-users] CErtificate profile validation >> >>_______________________________________________ >>Pki-users mailing list >>Pki-users at redhat.com >>https://www.redhat.com/mailman/listinfo/pki-users >> >> From arshad.noor at strongauth.com Mon Mar 22 17:36:19 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Mon, 22 Mar 2010 09:36:19 -0800 (GMT-08:00) Subject: [Pki-users] CErtificate profile validation In-Reply-To: Message-ID: <17129293.61269279379760.JavaMail.root@gw.noorhome.net> In order to accomplish what you're doing, Shanthi, what you need to do is have two profiles - one at the RA that performs verification tasks, and one at the CA that performs modifications. So, for example, you were creating a custom profile for a "Basic Assurance Signing Profile" (the name is just an example), you would use the same profile at the RA and the CA instances, but configure the profile at the RA to only verify the information you were expecting from the end-entity (such as name-form, key-size, key-type, etc.) and then send it to the CA where the profile adds the required extensions and constraints. What is confusing for many RHCS/DogTag users is that while the same profile can exist on the RA and the CA, they do not see each others' profile configurations - they only see their own configurations. You likely configured the profile at the RA instance, which the CA is logically ignoring. Modify/create your profile at the CA instance and you will get the certificates you want. Arshad Noor StrongAuth, Inc. ----- Original Message ----- From: "Thomas Shanthi-LST016" To: "Arshad Noor" Cc: pki-users at redhat.com Sent: Monday, March 22, 2010 9:48:28 AM (GMT-0800) America/Los_Angeles Subject: RE: [Pki-users] CErtificate profile validation Thanks, Arshad. Is there some way to enforce the CA to cross-check the CSR against the profile when the RA is also present? Or is this automatically enabled? I must have missed something when I set the cert preofile... When I tried this, it seemed as if the CA was not verifying correctness of the issued certificate against the cert profile. It seemed to be just adding its signature. Also it added the Authority Key Indentifier but not the subject key identifier (as per RFC 5280 it looks the CA adds this field) - though both were mentioned in the profile. >>-----Original Message----- >>From: Arshad Noor [mailto:arshad.noor at strongauth.com] >>Sent: Monday, March 22, 2010 11:43 AM >>To: Thomas Shanthi-LST016 >>Cc: pki-users at redhat.com >>Subject: Re: [Pki-users] CErtificate profile validation >> >>Technically, it can occur at either or both locations. >>However, from a business and operational point-of-view, most >>PKIs do the verification at the RA. This is because it >>allows different RA's to use different policies, procedures >>and tools to do the key-generation, verification, etc., >>before sending the verified CSR to the CA for signing. >> >>From an operational point of view, having RAs do the >>verification allows you to scale a CA to sign more >>certificates in a given unit of time if it only had to sign >>certificates and CRLs instead of verifying and signing. >> >>Yes, the CA can indeed add all the required >>constraints/extensions as needed to the certificate based on >>the profile, before it signs the CSR. >> >>Arshad Noor >>StrongAuth, Inc. >> >>----- Original Message ----- >>From: "Thomas Shanthi-LST016" >>To: pki-users at redhat.com >>Sent: Monday, March 22, 2010 9:00:59 AM (GMT-0800) America/Los_Angeles >>Subject: [Pki-users] CErtificate profile validation >> >>_______________________________________________ >>Pki-users mailing list >>Pki-users at redhat.com >>https://www.redhat.com/mailman/listinfo/pki-users >> >> From Shanthi.Thomas at motorola.com Mon Mar 22 19:22:35 2010 From: Shanthi.Thomas at motorola.com (Thomas Shanthi-LST016) Date: Mon, 22 Mar 2010 15:22:35 -0400 Subject: [Pki-users] CErtificate profile validation In-Reply-To: <17129293.61269279379760.JavaMail.root@gw.noorhome.net> References: <17129293.61269279379760.JavaMail.root@gw.noorhome.net> Message-ID: Thanks again for the prompt reply, Arshad. I had created the profile at the CA but had not configured it on the RA (just to check if the CA was validating it). But I will try it out completely and get back again. Also, to confirm - when you say profile configuration at the RA and CA, I'm assuming you mean the modification of the .vm and .cgi files at the RA, and at the CA the profile configuration is specified via the PKI-console. Thanks, Shanthi >>-----Original Message----- >>From: Arshad Noor [mailto:arshad.noor at strongauth.com] >>Sent: Monday, March 22, 2010 12:36 PM >>To: Thomas Shanthi-LST016 >>Cc: pki-users at redhat.com >>Subject: Re: [Pki-users] CErtificate profile validation >> >>In order to accomplish what you're doing, Shanthi, what you >>need to do is have two profiles - one at the RA that performs >>verification tasks, and one at the CA that performs >>modifications. So, for example, you were creating a custom >>profile for a "Basic Assurance Signing Profile" >>(the name is just an example), you would use the same profile >>at the RA and the CA instances, but configure the profile at >>the RA to only verify the information you were expecting from >>the end-entity (such as name-form, key-size, key-type, etc.) >>and then send it to the CA where the profile adds the >>required extensions and constraints. >> >>What is confusing for many RHCS/DogTag users is that while >>the same profile can exist on the RA and the CA, they do not >>see each others' >>profile configurations - they only see their own >>configurations. You likely configured the profile at the RA >>instance, which the CA is logically ignoring. Modify/create >>your profile at the CA instance and you will get the >>certificates you want. >> >>Arshad Noor >>StrongAuth, Inc. >> >>----- Original Message ----- >>From: "Thomas Shanthi-LST016" >>To: "Arshad Noor" >>Cc: pki-users at redhat.com >>Sent: Monday, March 22, 2010 9:48:28 AM (GMT-0800) America/Los_Angeles >>Subject: RE: [Pki-users] CErtificate profile validation >> >>Thanks, Arshad. Is there some way to enforce the CA to >>cross-check the CSR against the profile when the RA is also >>present? Or is this automatically enabled? >> >>I must have missed something when I set the cert preofile... >>When I tried this, it seemed as if the CA was not verifying >>correctness of the issued certificate against the cert >>profile. It seemed to be just adding its signature. Also it >>added the Authority Key Indentifier but not the subject key >>identifier (as per RFC 5280 it looks the CA adds this field) >>- though both were mentioned in the profile. >> >>>>-----Original Message----- >>>>From: Arshad Noor [mailto:arshad.noor at strongauth.com] >>>>Sent: Monday, March 22, 2010 11:43 AM >>>>To: Thomas Shanthi-LST016 >>>>Cc: pki-users at redhat.com >>>>Subject: Re: [Pki-users] CErtificate profile validation >>>> >>>>Technically, it can occur at either or both locations. >>>>However, from a business and operational point-of-view, >>most PKIs do >>>>the verification at the RA. This is because it allows >>different RA's >>>>to use different policies, procedures and tools to do the >>>>key-generation, verification, etc., before sending the >>verified CSR to >>>>the CA for signing. >>>> >>>>From an operational point of view, having RAs do the verification >>>>allows you to scale a CA to sign more certificates in a >>given unit of >>>>time if it only had to sign certificates and CRLs instead >>of verifying >>>>and signing. >>>> >>>>Yes, the CA can indeed add all the required >>constraints/extensions as >>>>needed to the certificate based on the profile, before it signs the >>>>CSR. >>>> >>>>Arshad Noor >>>>StrongAuth, Inc. >>>> >>>>----- Original Message ----- >>>>From: "Thomas Shanthi-LST016" >>>>To: pki-users at redhat.com >>>>Sent: Monday, March 22, 2010 9:00:59 AM (GMT-0800) >>America/Los_Angeles >>>>Subject: [Pki-users] CErtificate profile validation >>>> >>>>_______________________________________________ >>>>Pki-users mailing list >>>>Pki-users at redhat.com >>>>https://www.redhat.com/mailman/listinfo/pki-users >>>> >>>> >> >> From arshad.noor at strongauth.com Mon Mar 22 19:33:46 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Mon, 22 Mar 2010 11:33:46 -0800 (GMT-08:00) Subject: [Pki-users] CErtificate profile validation In-Reply-To: Message-ID: <13301479.321269286426738.JavaMail.root@gw.noorhome.net> Hmmm... unless something has changed in a new version of the PKI software (it has been a few months since I last looked at DogTag), I've never had to modify a .vm or .cgi file to change a profile. The certificate profiles were always accessible through the PKI Console, regardless of whether it was an RA or CA instance. Arshad Noor StrongAuth, Inc. ----- Original Message ----- From: "Thomas Shanthi-LST016" To: "Arshad Noor" Cc: pki-users at redhat.com Sent: Monday, March 22, 2010 12:22:35 PM (GMT-0800) America/Los_Angeles Subject: RE: [Pki-users] CErtificate profile validation Thanks again for the prompt reply, Arshad. I had created the profile at the CA but had not configured it on the RA (just to check if the CA was validating it). But I will try it out completely and get back again. Also, to confirm - when you say profile configuration at the RA and CA, I'm assuming you mean the modification of the .vm and .cgi files at the RA, and at the CA the profile configuration is specified via the PKI-console. Thanks, Shanthi >>-----Original Message----- >>From: Arshad Noor [mailto:arshad.noor at strongauth.com] >>Sent: Monday, March 22, 2010 12:36 PM >>To: Thomas Shanthi-LST016 >>Cc: pki-users at redhat.com >>Subject: Re: [Pki-users] CErtificate profile validation >> >>In order to accomplish what you're doing, Shanthi, what you >>need to do is have two profiles - one at the RA that performs >>verification tasks, and one at the CA that performs >>modifications. So, for example, you were creating a custom >>profile for a "Basic Assurance Signing Profile" >>(the name is just an example), you would use the same profile >>at the RA and the CA instances, but configure the profile at >>the RA to only verify the information you were expecting from >>the end-entity (such as name-form, key-size, key-type, etc.) >>and then send it to the CA where the profile adds the >>required extensions and constraints. >> >>What is confusing for many RHCS/DogTag users is that while >>the same profile can exist on the RA and the CA, they do not >>see each others' >>profile configurations - they only see their own >>configurations. You likely configured the profile at the RA >>instance, which the CA is logically ignoring. Modify/create >>your profile at the CA instance and you will get the >>certificates you want. >> >>Arshad Noor >>StrongAuth, Inc. >> >>----- Original Message ----- >>From: "Thomas Shanthi-LST016" >>To: "Arshad Noor" >>Cc: pki-users at redhat.com >>Sent: Monday, March 22, 2010 9:48:28 AM (GMT-0800) America/Los_Angeles >>Subject: RE: [Pki-users] CErtificate profile validation >> >>Thanks, Arshad. Is there some way to enforce the CA to >>cross-check the CSR against the profile when the RA is also >>present? Or is this automatically enabled? >> >>I must have missed something when I set the cert preofile... >>When I tried this, it seemed as if the CA was not verifying >>correctness of the issued certificate against the cert >>profile. It seemed to be just adding its signature. Also it >>added the Authority Key Indentifier but not the subject key >>identifier (as per RFC 5280 it looks the CA adds this field) >>- though both were mentioned in the profile. >> >>>>-----Original Message----- >>>>From: Arshad Noor [mailto:arshad.noor at strongauth.com] >>>>Sent: Monday, March 22, 2010 11:43 AM >>>>To: Thomas Shanthi-LST016 >>>>Cc: pki-users at redhat.com >>>>Subject: Re: [Pki-users] CErtificate profile validation >>>> >>>>Technically, it can occur at either or both locations. >>>>However, from a business and operational point-of-view, >>most PKIs do >>>>the verification at the RA. This is because it allows >>different RA's >>>>to use different policies, procedures and tools to do the >>>>key-generation, verification, etc., before sending the >>verified CSR to >>>>the CA for signing. >>>> >>>>From an operational point of view, having RAs do the verification >>>>allows you to scale a CA to sign more certificates in a >>given unit of >>>>time if it only had to sign certificates and CRLs instead >>of verifying >>>>and signing. >>>> >>>>Yes, the CA can indeed add all the required >>constraints/extensions as >>>>needed to the certificate based on the profile, before it signs the >>>>CSR. >>>> >>>>Arshad Noor >>>>StrongAuth, Inc. >>>> >>>>----- Original Message ----- >>>>From: "Thomas Shanthi-LST016" >>>>To: pki-users at redhat.com >>>>Sent: Monday, March 22, 2010 9:00:59 AM (GMT-0800) >>America/Los_Angeles >>>>Subject: [Pki-users] CErtificate profile validation >>>> >>>>_______________________________________________ >>>>Pki-users mailing list >>>>Pki-users at redhat.com >>>>https://www.redhat.com/mailman/listinfo/pki-users >>>> >>>> >> >> From Shanthi.Thomas at motorola.com Tue Mar 23 15:31:26 2010 From: Shanthi.Thomas at motorola.com (Thomas Shanthi-LST016) Date: Tue, 23 Mar 2010 11:31:26 -0400 Subject: [Pki-users] CErtificate profile validation References: <13301479.321269286426738.JavaMail.root@gw.noorhome.net> Message-ID: Hi Arshad, I'm glad I asked the question. I have been reading the REdhat manuals to understand about dogtag - I knew these were not on the latest dogtag release i.e 1.3; but that was the most detailed documentation available. I have been trying to determine how to bring up the pkiconsole for the RA - but it eludes me. When I start the RA using 'service pki-rad create '. I do not see the pki console listed - it lists the URLs associated with the RA for agent, EE, etc. However, when I start the CA in a similar manner, the command for starting the PKI console is listed. So I am confused. So the question is, how do I bring up the PKI RA Console? Thanks! Shanthi -----Original Message----- From: Arshad Noor [mailto:arshad.noor at strongauth.com] Sent: Mon 3/22/2010 3:33 PM To: Thomas Shanthi-LST016 Cc: pki-users at redhat.com Subject: Re: [Pki-users] CErtificate profile validation Hmmm... unless something has changed in a new version of the PKI software (it has been a few months since I last looked at DogTag), I've never had to modify a .vm or .cgi file to change a profile. The certificate profiles were always accessible through the PKI Console, regardless of whether it was an RA or CA instance. Arshad Noor StrongAuth, Inc. ----- Original Message ----- From: "Thomas Shanthi-LST016" To: "Arshad Noor" Cc: pki-users at redhat.com Sent: Monday, March 22, 2010 12:22:35 PM (GMT-0800) America/Los_Angeles Subject: RE: [Pki-users] CErtificate profile validation Thanks again for the prompt reply, Arshad. I had created the profile at the CA but had not configured it on the RA (just to check if the CA was validating it). But I will try it out completely and get back again. Also, to confirm - when you say profile configuration at the RA and CA, I'm assuming you mean the modification of the .vm and .cgi files at the RA, and at the CA the profile configuration is specified via the PKI-console. Thanks, Shanthi >>-----Original Message----- >>From: Arshad Noor [mailto:arshad.noor at strongauth.com] >>Sent: Monday, March 22, 2010 12:36 PM >>To: Thomas Shanthi-LST016 >>Cc: pki-users at redhat.com >>Subject: Re: [Pki-users] CErtificate profile validation >> >>In order to accomplish what you're doing, Shanthi, what you >>need to do is have two profiles - one at the RA that performs >>verification tasks, and one at the CA that performs >>modifications. So, for example, you were creating a custom >>profile for a "Basic Assurance Signing Profile" >>(the name is just an example), you would use the same profile >>at the RA and the CA instances, but configure the profile at >>the RA to only verify the information you were expecting from >>the end-entity (such as name-form, key-size, key-type, etc.) >>and then send it to the CA where the profile adds the >>required extensions and constraints. >> >>What is confusing for many RHCS/DogTag users is that while >>the same profile can exist on the RA and the CA, they do not >>see each others' >>profile configurations - they only see their own >>configurations. You likely configured the profile at the RA >>instance, which the CA is logically ignoring. Modify/create >>your profile at the CA instance and you will get the >>certificates you want. >> >>Arshad Noor >>StrongAuth, Inc. >> >>----- Original Message ----- >>From: "Thomas Shanthi-LST016" >>To: "Arshad Noor" >>Cc: pki-users at redhat.com >>Sent: Monday, March 22, 2010 9:48:28 AM (GMT-0800) America/Los_Angeles >>Subject: RE: [Pki-users] CErtificate profile validation >> >>Thanks, Arshad. Is there some way to enforce the CA to >>cross-check the CSR against the profile when the RA is also >>present? Or is this automatically enabled? >> >>I must have missed something when I set the cert preofile... >>When I tried this, it seemed as if the CA was not verifying >>correctness of the issued certificate against the cert >>profile. It seemed to be just adding its signature. Also it >>added the Authority Key Indentifier but not the subject key >>identifier (as per RFC 5280 it looks the CA adds this field) >>- though both were mentioned in the profile. >> >>>>-----Original Message----- >>>>From: Arshad Noor [mailto:arshad.noor at strongauth.com] >>>>Sent: Monday, March 22, 2010 11:43 AM >>>>To: Thomas Shanthi-LST016 >>>>Cc: pki-users at redhat.com >>>>Subject: Re: [Pki-users] CErtificate profile validation >>>> >>>>Technically, it can occur at either or both locations. >>>>However, from a business and operational point-of-view, >>most PKIs do >>>>the verification at the RA. This is because it allows >>different RA's >>>>to use different policies, procedures and tools to do the >>>>key-generation, verification, etc., before sending the >>verified CSR to >>>>the CA for signing. >>>> >>>>From an operational point of view, having RAs do the verification >>>>allows you to scale a CA to sign more certificates in a >>given unit of >>>>time if it only had to sign certificates and CRLs instead >>of verifying >>>>and signing. >>>> >>>>Yes, the CA can indeed add all the required >>constraints/extensions as >>>>needed to the certificate based on the profile, before it signs the >>>>CSR. >>>> >>>>Arshad Noor >>>>StrongAuth, Inc. >>>> >>>>----- Original Message ----- >>>>From: "Thomas Shanthi-LST016" >>>>To: pki-users at redhat.com >>>>Sent: Monday, March 22, 2010 9:00:59 AM (GMT-0800) >>America/Los_Angeles >>>>Subject: [Pki-users] CErtificate profile validation >>>> >>>>_______________________________________________ >>>>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 arshad.noor at strongauth.com Tue Mar 23 17:42:37 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Tue, 23 Mar 2010 09:42:37 -0800 (GMT-08:00) Subject: [Pki-users] CErtificate profile validation In-Reply-To: Message-ID: <3185168.551269366157108.JavaMail.root@gw.noorhome.net> DogTag and RHCS follows a similar architecture regardless of which component is being managed (RA, CA, DRM, etc.). No matter which sub-system is running on your machine (unless you have two sub-systems on your machine), the "Admin" port listens for connections from the PKI console. When you installed the RA instance, you chose an Admin port (or it was chosen for you by default); all you need to do is bring up the PKI Console in exactly the same way you would on the CA, but connect to the hostname/port combination corresponding to the RA instance. However, the Admin server has to be running to respond to the connection. Arshad Noor StrongAuth, Inc. ----- Original Message ----- From: "Thomas Shanthi-LST016" To: "Arshad Noor" Cc: pki-users at redhat.com Sent: Tuesday, March 23, 2010 8:31:26 AM (GMT-0800) America/Los_Angeles Subject: RE: [Pki-users] CErtificate profile validation Hi Arshad, I'm glad I asked the question. I have been reading the REdhat manuals to understand about dogtag - I knew these were not on the latest dogtag release i.e 1.3; but that was the most detailed documentation available. I have been trying to determine how to bring up the pkiconsole for the RA - but it eludes me. When I start the RA using 'service pki-rad create '. I do not see the pki console listed - it lists the URLs associated with the RA for agent, EE, etc. However, when I start the CA in a similar manner, the command for starting the PKI console is listed. So I am confused. So the question is, how do I bring up the PKI RA Console? Thanks! Shanthi -----Original Message----- From: Arshad Noor [ mailto:arshad.noor at strongauth.com ] Sent: Mon 3/22/2010 3:33 PM To: Thomas Shanthi-LST016 Cc: pki-users at redhat.com Subject: Re: [Pki-users] CErtificate profile validation Hmmm... unless something has changed in a new version of the PKI software (it has been a few months since I last looked at DogTag), I've never had to modify a .vm or .cgi file to change a profile. The certificate profiles were always accessible through the PKI Console, regardless of whether it was an RA or CA instance. Arshad Noor StrongAuth, Inc. ----- Original Message ----- From: "Thomas Shanthi-LST016" < Shanthi.Thomas at motorola.com > To: "Arshad Noor" < arshad.noor at strongauth.com > Cc: pki-users at redhat.com Sent: Monday, March 22, 2010 12:22:35 PM (GMT-0800) America/Los_Angeles Subject: RE: [Pki-users] CErtificate profile validation Thanks again for the prompt reply, Arshad. I had created the profile at the CA but had not configured it on the RA (just to check if the CA was validating it). But I will try it out completely and get back again. Also, to confirm - when you say profile configuration at the RA and CA, I'm assuming you mean the modification of the .vm and .cgi files at the RA, and at the CA the profile configuration is specified via the PKI-console. Thanks, Shanthi >>-----Original Message----- >>From: Arshad Noor [ mailto:arshad.noor at strongauth.com ] >>Sent: Monday, March 22, 2010 12:36 PM >>To: Thomas Shanthi-LST016 >>Cc: pki-users at redhat.com >>Subject: Re: [Pki-users] CErtificate profile validation >> >>In order to accomplish what you're doing, Shanthi, what you >>need to do is have two profiles - one at the RA that performs >>verification tasks, and one at the CA that performs >>modifications. So, for example, you were creating a custom >>profile for a "Basic Assurance Signing Profile" >>(the name is just an example), you would use the same profile >>at the RA and the CA instances, but configure the profile at >>the RA to only verify the information you were expecting from >>the end-entity (such as name-form, key-size, key-type, etc.) >>and then send it to the CA where the profile adds the >>required extensions and constraints. >> >>What is confusing for many RHCS/DogTag users is that while >>the same profile can exist on the RA and the CA, they do not >>see each others' >>profile configurations - they only see their own >>configurations. You likely configured the profile at the RA >>instance, which the CA is logically ignoring. Modify/create >>your profile at the CA instance and you will get the >>certificates you want. >> >>Arshad Noor >>StrongAuth, Inc. >> >>----- Original Message ----- >>From: "Thomas Shanthi-LST016" < Shanthi.Thomas at motorola.com > >>To: "Arshad Noor" < arshad.noor at strongauth.com > >>Cc: pki-users at redhat.com >>Sent: Monday, March 22, 2010 9:48:28 AM (GMT-0800) America/Los_Angeles >>Subject: RE: [Pki-users] CErtificate profile validation >> >>Thanks, Arshad. Is there some way to enforce the CA to >>cross-check the CSR against the profile when the RA is also >>present? Or is this automatically enabled? >> >>I must have missed something when I set the cert preofile... >>When I tried this, it seemed as if the CA was not verifying >>correctness of the issued certificate against the cert >>profile. It seemed to be just adding its signature. Also it >>added the Authority Key Indentifier but not the subject key >>identifier (as per RFC 5280 it looks the CA adds this field) >>- though both were mentioned in the profile. >> >>>>-----Original Message----- >>>>From: Arshad Noor [ mailto:arshad.noor at strongauth.com ] >>>>Sent: Monday, March 22, 2010 11:43 AM >>>>To: Thomas Shanthi-LST016 >>>>Cc: pki-users at redhat.com >>>>Subject: Re: [Pki-users] CErtificate profile validation >>>> >>>>Technically, it can occur at either or both locations. >>>>However, from a business and operational point-of-view, >>most PKIs do >>>>the verification at the RA. This is because it allows >>different RA's >>>>to use different policies, procedures and tools to do the >>>>key-generation, verification, etc., before sending the >>verified CSR to >>>>the CA for signing. >>>> >>>>From an operational point of view, having RAs do the verification >>>>allows you to scale a CA to sign more certificates in a >>given unit of >>>>time if it only had to sign certificates and CRLs instead >>of verifying >>>>and signing. >>>> >>>>Yes, the CA can indeed add all the required >>constraints/extensions as >>>>needed to the certificate based on the profile, before it signs the >>>>CSR. >>>> >>>>Arshad Noor >>>>StrongAuth, Inc. >>>> >>>>----- Original Message ----- >>>>From: "Thomas Shanthi-LST016" < Shanthi.Thomas at motorola.com > >>>>To: pki-users at redhat.com >>>>Sent: Monday, March 22, 2010 9:00:59 AM (GMT-0800) >>America/Los_Angeles >>>>Subject: [Pki-users] CErtificate profile validation >>>> >>>>_______________________________________________ >>>>Pki-users mailing list >>>> Pki-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-users >>>> >>>> >> >> From ehimawan at gmail.com Wed Mar 24 20:59:17 2010 From: ehimawan at gmail.com (Erwin Himawan) Date: Wed, 24 Mar 2010 15:59:17 -0500 Subject: [Pki-users] SCEP: List Request: "Error Certificate Not Issued." However, certificate is issued successfully to client Message-ID: <2b8d35db1003241359m282303acy8bb5e3f776d5b286@mail.gmail.com> Hi All, I have been playing with DCS in a test environment and so far I am happy with its functionalities. During the SCEP test, I looked into various information generated by the CA in processing a SCEP request. However, I noticed that the information obtained through the "list request" was not consistent with the information obtained from the "list certificate." According to the "list request" my SCEP request encountered an error and the certificate was not issued. However, in the "List Certificate", this SCEP request was successfully processed and resulted in the issuance of a certificate. Likewise, at the SCEP client, the SCEP client also successfully obtained the certificate. Is this a bug or my SCEP test procedure is not correct? Here is my SCEP test procedure: 1. Using the RA webform, I applied for a SCEP PIN 2. Logging in as an RA, I approved the PIN request, the output of this approval is a PIN which I distributed it to the SCEP client using out of band method. 3. My SCEP client is Simple SCEP (sscep). 4. Using the mkrequest -ip 10.8.122.131 [PIN], I created the CSR. I could see that the PIN is included in the CSR as the challenge-password attribute 5. Assuming I have successfully obtained the CA certificate, using the sscep enroll -c ca.crt -k local.key -r local.csr -l local.crt -u http://ra.fqdn:12888/ee/scep/pkiclient.cgi, I started SCEP enrollment 6. After a quick wait time, my SCEP client obtained the certificate from the CA. After the CA has successfully issued this certificate to my SCEP client, I checked the CA "list requests" and "list certificates" pages. At the "list request" page, I filtered for all type of request and all status of requests. The output of this query is formatted into three colums; "status", "assigned to", and "subject." My SCEP client request has "status=completed". The assigned to and subject are empty. Further opening this record, the CA indicates that there is an error; i.e. the issued certificate section contained: "Error Certificate Not Issued" When I opened the "list certificates" and searched for the SCEP client certificate, the SCEP client certificate was there with status "valid" Thanks in advance. Regards, Erwin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ehimawan at gmail.com Thu Mar 25 23:25:49 2010 From: ehimawan at gmail.com (Erwin Himawan) Date: Thu, 25 Mar 2010 18:25:49 -0500 Subject: [Pki-users] SCEP Question Message-ID: <2b8d35db1003251625g6f50f4e5hdcc8567ea085b6c2@mail.gmail.com> Hi All, Has someone confirm that dogtag can be configured such that a SCEP request from a router is approved manually by an agent at the CA or RA? The following are the steps I do to test this scenario: 1. In the CA, I create a profile, called router profile. 2. This router profile is similar to the caRouterCert profile 3. In this profile, I disable the visibility such that this profile is not visible in the CA's end-entity web page. 4. The profile's Certificate Profile Authentication filed is left empty; implying that the request will be handled by the CA agent. 5. I am using Simple SCEP as my SCEP client. 6. At the sscep client, I generate a CSR using mkrequest. During CSR generation using the mkrequest, I did not include PIN (or challenge-response PIN), since did not ask the RA to generate a PIN for me. The reason is, I would like the agent to manually approve the request. 7. using sscep enroll, I made the scep client to send SCEP enroll to the CA ./sscep enroll -c ca.crt -k local.key -r local.csr -l local.crt -u http://ca.fqdn:9180/ca/cgi-bin/pkiclient.exe 8. I turned on sscep debug and verbose. From this debug and verbose output, I observed that the scep client sends HTTP GET /ca/cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIIH3A................. 9. Also from the sscep debug message, I noticed that the CA responses with status code 200. The CA sends a PKCS7 payload. 10. Inside the payload is the router certificate. My question is:. Why the CA does not queue this request for agent approval? Thanks in advance, Erwin -------------- next part -------------- An HTML attachment was scrubbed... URL: From Patrick.Raspante at gdc4s.com Fri Mar 26 11:47:06 2010 From: Patrick.Raspante at gdc4s.com (Raspante, Patrick) Date: Fri, 26 Mar 2010 07:47:06 -0400 Subject: [Pki-users] Manually Replacing Server Certificates + Profiles Message-ID: Using CS 8.0, I'm interested in replacing (not renewing) all the server certificates for every subsystem (CA,TKS,DRM,TPS). The solution I had planned on using was to painstakingly use certutil to generate certificate requests, sign then, and import them back into the subsystem cert db with identical cert nicknames. Is there an easier way to do this (other than reinstalling+rerunning the create wizard)? I can attempt to use pkiconsole to replace certificates and automatically send them to the CA's ee page, but that seems to be erroring repeatedly. Using the certutil method, I'm unsure of which CA profiles to use when signing some of the server certificates certificates. For example, when replacing the TKS's 'subsystemCert' or 'Server-Cert' using the CA's 'manual server certificate enrollment' profile, I don't a get a cert with identical extensions as the original TKS 'subsytem cert'. Which profile does the CA use at TKS creation-time for these certs? Thanks Patrick Raspante Software Engineer General Dynamics C4 Systems Work: 781-455-2399 This message and/or attachments may include information subject to GDC4S O.M. 1.8.6 and GD Corporate Policy 07-105 and is intended to be accessed only by authorized recipients. Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties. Recipients should refer to the policies or contract to determine proper handling. Unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Fri Mar 26 16:55:43 2010 From: jmagne at redhat.com (John Magne) Date: Fri, 26 Mar 2010 12:55:43 -0400 (EDT) Subject: [Pki-users] Manually Replacing Server Certificates + Profiles In-Reply-To: Message-ID: <1967264837.52471269622543311.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> Patrick: I did some quick digging and came up with a bit of info that might help. It looks like the profiles that actually get used by the configuration wizard to create subsystems are private to that process. You can though, view these profiles in the directory: /var/lib/pki-ca/conf/*.profile The differences between these profiles and the regular CA profiles can be compared to possibly explain what you are seeing with the certs that get output. ----- Original Message ----- From: "Patrick Raspante" To: pki-users at redhat.com Sent: Friday, March 26, 2010 4:47:06 AM GMT -08:00 US/Canada Pacific Subject: [Pki-users] Manually Replacing Server Certificates + Profiles Manually Replacing Server Certificates + Profiles Using CS 8.0, I'm interested in replacing (not renewing) all the server certificates for every subsystem (CA,TKS,DRM,TPS). The solution I had planned on using was to painstakingly use certutil to generate certificate requests, sign then, and import them back into the subsystem cert db with identical cert nicknames. Is there an easier way to do this (other than reinstalling+rerunning the create wizard)? I can attempt to use pkiconsole to replace certificates and automatically send them to the CA's ee page, but that seems to be erroring repeatedly. Using the certutil method, I'm unsure of which CA profiles to use when signing some of the server certificates certificates. For example, when replacing the TKS's 'subsystemCert' or 'Server-Cert' using the CA's 'manual server certificate enrollment' profile, I don't a get a cert with identical extensions as the original TKS 'subsytem cert'. Which profile does the CA use at TKS creation-time for these certs? Thanks Patrick Raspante Software Engineer General Dynamics C4 Systems Work: 781-455-2399 This message and/or attachments may include information subject to GDC4S O.M. 1.8.6 and GD Corporate Policy 07-105 and is intended to be accessed only by authorized recipients. Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties. Recipients should refer to the policies or contract to determine proper handling. Unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender and destroy all copies of the original message. _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users From sean.veale at gdc4s.com Fri Mar 26 17:14:53 2010 From: sean.veale at gdc4s.com (Veale, Sean) Date: Fri, 26 Mar 2010 13:14:53 -0400 Subject: [Pki-users] Manually Replacing Server Certificates + Profiles In-Reply-To: <1967264837.52471269622543311.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> References: <1967264837.52471269622543311.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> Message-ID: <5E904A528F23FA469961CECAC5F41787024EA163@NDHMC4SXCH.gdc4s.com> Hi That does help. Thanks Sean -----Original Message----- From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of John Magne Sent: Friday, March 26, 2010 12:56 PM To: Raspante, Patrick Cc: pki-users at redhat.com Subject: Re: [Pki-users] Manually Replacing Server Certificates + Profiles Patrick: I did some quick digging and came up with a bit of info that might help. It looks like the profiles that actually get used by the configuration wizard to create subsystems are private to that process. You can though, view these profiles in the directory: /var/lib/pki-ca/conf/*.profile The differences between these profiles and the regular CA profiles can be compared to possibly explain what you are seeing with the certs that get output. ----- Original Message ----- From: "Patrick Raspante" To: pki-users at redhat.com Sent: Friday, March 26, 2010 4:47:06 AM GMT -08:00 US/Canada Pacific Subject: [Pki-users] Manually Replacing Server Certificates + Profiles Manually Replacing Server Certificates + Profiles Using CS 8.0, I'm interested in replacing (not renewing) all the server certificates for every subsystem (CA,TKS,DRM,TPS). The solution I had planned on using was to painstakingly use certutil to generate certificate requests, sign then, and import them back into the subsystem cert db with identical cert nicknames. Is there an easier way to do this (other than reinstalling+rerunning the create wizard)? I can attempt to use pkiconsole to replace certificates and automatically send them to the CA's ee page, but that seems to be erroring repeatedly. Using the certutil method, I'm unsure of which CA profiles to use when signing some of the server certificates certificates. For example, when replacing the TKS's 'subsystemCert' or 'Server-Cert' using the CA's 'manual server certificate enrollment' profile, I don't a get a cert with identical extensions as the original TKS 'subsytem cert'. Which profile does the CA use at TKS creation-time for these certs? Thanks Patrick Raspante Software Engineer General Dynamics C4 Systems Work: 781-455-2399 This message and/or attachments may include information subject to GDC4S O.M. 1.8.6 and GD Corporate Policy 07-105 and is intended to be accessed only by authorized recipients. Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties. Recipients should refer to the policies or contract to determine proper handling. Unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender and destroy all copies of the original message. _______________________________________________ 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 arshad.noor at strongauth.com Fri Mar 26 17:15:18 2010 From: arshad.noor at strongauth.com (Arshad Noor) Date: Fri, 26 Mar 2010 10:15:18 -0700 Subject: [Pki-users] Manually Replacing Server Certificates + Profiles In-Reply-To: References: Message-ID: <4BACEBA6.9030308@strongauth.com> Could you elaborate why you see a need to do this, Patrick? I'm curious. Thanks. Arshad Noor StrongAuth, Inc. Raspante, Patrick wrote: > I'm interested in replacing (not renewing) all the server certificates > for every subsystem (CA,TKS,DRM,TPS). > From Didier.Moens at dmbr.vib-UGent.be Fri Mar 19 22:36:56 2010 From: Didier.Moens at dmbr.vib-UGent.be (Didier Moens) Date: Fri, 19 Mar 2010 22:36:56 -0000 Subject: [Pki-users] Unable to connect to Secure Admin Port In-Reply-To: <4B9A6A25.8020905@dmbr.vib-UGent.be> References: <4B867C14.9000901@dmbr.vib-UGent.be> <4B9A6A25.8020905@dmbr.vib-UGent.be> Message-ID: <4BA3FC76.9010306@dmbr.vib-UGent.be> On 12/03/10 17:21, Didier Moens wrote: > Dear Erwin, > > Your reply is much appreciated ; apologies for not responding sooner, as > I was busy examining some alternative Dogtag paths (without success, see > below). > To whom it may concern : Dogtag PKI has been confirmed non-functional on RHEL/CentOS for the moment being (https://bugzilla.redhat.com/show_bug.cgi?id=573038). Best regards, Didier -- =================================================================== Didier Moens IT services Department for Molecular Biomedical Research (DMBR) VIB - Ghent University Fiers-Schell-Van Montagu Research Building Technologiepark 927 , B-9052 Zwijnaarde , Belgium tel ++32(9)3313605 fax ++32(9)3313609 mailto:Didier.Moens at dmbr.vib-UGent.be http://www.dmbr.UGent.be =================================================================== This message represents the official view of the voices in my head.