From Oleg.Antonenko at adaptivemobile.com Tue Oct 1 11:08:38 2013 From: Oleg.Antonenko at adaptivemobile.com (Oleg Antonenko) Date: Tue, 1 Oct 2013 11:08:38 +0000 Subject: [Pki-users] pki-ca-9.0.3-30 setup Message-ID: <34A5A0661B86944184C25952A4F169908691FB57@Exchange-AMS.adaptivemobile.com> Hello there! Could you help with the CA setup please? We installed a new machine with CentOS release 6.4 (Final) and installed the pki-ca-9.0.3-30 package. The command we used for creation was: pkicreate -pki_instance_root=/var/lib \ -pki_instance_name=pki-ca \ -subsystem_type=ca \ -agent_secure_port=9443 \ -ee_secure_port=9444 \ -ee_secure_client_auth_port=9446 \ -admin_secure_port=9445 \ -unsecure_port=9180 \ -tomcat_server_port=9701 \ -user=pkiuser \ -group=pkiuser \ -redirect conf=/etc/pki-ca \ -redirect logs=/var/log/pki-ca \ -verbose After clicking through the wizard and restarting the service: status: [root at jdrhel2 ~]# /sbin/service pki-cad status pki-ca pki-ca (pid 4988) is running... [ OK ] Unsecure Port = http://jdrhel2:9180/ca/ee/ca Secure Agent Port = https://jdrhel2:9443/ca/agent/ca Secure EE Port = https://jdrhel2:9444/ca/ee/ca Secure Admin Port = https://jdrhel2:9445/ca/services EE Client Auth Port = https://jdrhel2:9446/ca/eeca/ca PKI Console Port = pkiconsole https://jdrhel2:9445/ca Tomcat Port = 9701 (for shutdown) PKI Instance Name: pki-ca PKI Subsystem Type: Root CA (Security Domain) Registered PKI Security Domain Information: ========================================================================== Name: AMSDomain URL: https://jdrhel2:9445 ========================================================================== Everything seems to be running, but when i connect to the adresses above, i can see firefox is verifying server certificate, uses personal certificate, but then the page is empty. To be precise, there are just two links leading to empty pages: - link 'SSL End Users Services' pointing at https://jdrhel2:9444/ca/ee/ca and - link 'Agent Services' pointing at https://jdrhel2:9443/ca/agent/ca Is there anything we did wrong or forgot to configure? Many thanks, Oleg From mdemansana at philasd.org Tue Oct 1 11:49:49 2013 From: mdemansana at philasd.org (Taggart, Michelle) Date: Tue, 1 Oct 2013 07:49:49 -0400 (EDT) Subject: [Pki-users] pki-ca-9.0.3-30 setup In-Reply-To: <34A5A0661B86944184C25952A4F169908691FB57@Exchange-AMS.adaptivemobile.com> Message-ID: <1193695098.31145.1380628189114.JavaMail.root@mail02.philasd.org> I believe you'll have to also install a theme. On the CentOS package, themes are not included. Thanks, Michelle T ----- Original Message ----- From: Oleg Antonenko To: pki-users at redhat.com Cc: Jindrich Dolezal , Ciaran Bradley Sent: Tue, 01 Oct 2013 07:08:38 -0400 (EDT) Subject: [Pki-users] pki-ca-9.0.3-30 setup Hello there! Could you help with the CA setup please? We installed a new machine with CentOS release 6.4 (Final) and installed the pki-ca-9.0.3-30 package. The command we used for creation was: pkicreate -pki_instance_root=/var/lib -pki_instance_name=pki-ca -subsystem_type=ca -agent_secure_port=9443 -ee_secure_port=9444 -ee_secure_client_auth_port=9446 -admin_secure_port=9445 -unsecure_port=9180 -tomcat_server_port=9701 -user=pkiuser -group=pkiuser -redirect conf=/etc/pki-ca -redirect logs=/var/log/pki-ca -verbose After clicking through the wizard and restarting the service: status: [root at jdrhel2 ~]# /sbin/service pki-cad status pki-ca pki-ca (pid 4988) is running... [ OK ] Unsecure Port = http://jdrhel2:9180/ca/ee/ca Secure Agent Port = https://jdrhel2:9443/ca/agent/ca Secure EE Port = https://jdrhel2:9444/ca/ee/ca Secure Admin Port = https://jdrhel2:9445/ca/services EE Client Auth Port = https://jdrhel2:9446/ca/eeca/ca PKI Console Port = pkiconsole https://jdrhel2:9445/ca Tomcat Port = 9701 (for shutdown) PKI Instance Name: pki-ca PKI Subsystem Type: Root CA (Security Domain) Registered PKI Security Domain Information: ========================================================================== Name: AMSDomain URL: https://jdrhel2:9445 ========================================================================== Everything seems to be running, but when i connect to the adresses above, i can see firefox is verifying server certificate, uses personal certificate, but then the page is empty. To be precise, there are just two links leading to empty pages: - link 'SSL End Users Services' pointing at https://jdrhel2:9444/ca/ee/ca and - link 'Agent Services' pointing at https://jdrhel2:9443/ca/agent/ca Is there anything we did wrong or forgot to configure? Many thanks, Oleg _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users From Oleg.Antonenko at adaptivemobile.com Wed Oct 2 10:03:05 2013 From: Oleg.Antonenko at adaptivemobile.com (Oleg Antonenko) Date: Wed, 2 Oct 2013 10:03:05 +0000 Subject: [Pki-users] pki-ca-9.0.3-30 setup In-Reply-To: <524ACA87.3060009@adaptivemobile.com> References: <1193695098.31145.1380628189114.JavaMail.root@mail02.philasd.org> <524ACA87.3060009@adaptivemobile.com> Message-ID: <34A5A0661B86944184C25952A4F169908691FD57@Exchange-AMS.adaptivemobile.com> Hi there! Are there any other suggestions regarding below? Many thanks, Oleg -----Original Message----- From: Jindrich Dolezal Sent: 01 October 2013 14:14 To: Taggart, Michelle Cc: Oleg Antonenko; pki-users at redhat.com; Ciaran Bradley Subject: Re: [Pki-users] pki-ca-9.0.3-30 setup hi, there are some themes installed : [root at jdrhel2 pki-ca]# rpm -qa | grep pki | grep theme ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-pki-common-theme-9.0.3-7.el6.noarch do we need some more themes? thanks jd On 10/01/2013 01:49 PM, Taggart, Michelle wrote: > I believe you'll have to also install a theme. On the CentOS package, themes are not included. > > > Thanks, > > Michelle T > > ----- Original Message ----- > From: Oleg Antonenko > To: pki-users at redhat.com > Cc: Jindrich Dolezal , Ciaran > Bradley > Sent: Tue, 01 Oct 2013 07:08:38 -0400 (EDT) > Subject: [Pki-users] pki-ca-9.0.3-30 setup > > Hello there! > Could you help with the CA setup please? > > We installed a new machine with CentOS release 6.4 (Final) and installed the pki-ca-9.0.3-30 package. > The command we used for creation was: > > pkicreate -pki_instance_root=/var/lib > -pki_instance_name=pki-ca > -subsystem_type=ca > -agent_secure_port=9443 > -ee_secure_port=9444 > -ee_secure_client_auth_port=9446 > -admin_secure_port=9445 > -unsecure_port=9180 > -tomcat_server_port=9701 > -user=pkiuser > -group=pkiuser > -redirect conf=/etc/pki-ca > -redirect logs=/var/log/pki-ca > -verbose > > After clicking through the wizard and restarting the service: > > status: > [root at jdrhel2 ~]# /sbin/service pki-cad status pki-ca pki-ca (pid > 4988) is running... [ OK ] > Unsecure Port = http://jdrhel2:9180/ca/ee/ca > Secure Agent Port = https://jdrhel2:9443/ca/agent/ca > Secure EE Port = https://jdrhel2:9444/ca/ee/ca > Secure Admin Port = https://jdrhel2:9445/ca/services > EE Client Auth Port = https://jdrhel2:9446/ca/eeca/ca > PKI Console Port = pkiconsole https://jdrhel2:9445/ca > Tomcat Port = 9701 (for shutdown) > > PKI Instance Name: pki-ca > PKI Subsystem Type: Root CA (Security Domain) > > Registered PKI Security Domain Information: > ========================================================================== > Name: AMSDomain > URL: https://jdrhel2:9445 > ====================================================================== > ==== > > Everything seems to be running, but when i connect to the adresses above, i can see firefox is verifying server certificate, uses personal certificate, but then the page is empty. > To be precise, there are just two links leading to empty pages: > - link 'SSL End Users Services' pointing at https://jdrhel2:9444/ca/ee/ca and > - link 'Agent Services' pointing at https://jdrhel2:9443/ca/agent/ca > > Is there anything we did wrong or forgot to configure? > > Many thanks, > Oleg > > > > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > From alee at redhat.com Wed Oct 2 13:56:05 2013 From: alee at redhat.com (Ade Lee) Date: Wed, 02 Oct 2013 09:56:05 -0400 Subject: [Pki-users] pki-ca-9.0.3-30 setup In-Reply-To: <34A5A0661B86944184C25952A4F169908691FD57@Exchange-AMS.adaptivemobile.com> References: <1193695098.31145.1380628189114.JavaMail.root@mail02.philasd.org> <524ACA87.3060009@adaptivemobile.com> <34A5A0661B86944184C25952A4F169908691FD57@Exchange-AMS.adaptivemobile.com> Message-ID: <1380722165.2503.5.camel@localhost.localdomain> The ipa-pki-ca-theme is a very crippled version of the real theme. Basically, dogtag 9 is in RHEL6 and hence, Centos 6, to support IPA, which does not use a UI to interact with the CA. I would install the dogtag-pki-theme package from fedora 17 -- http://koji.fedoraproject.org/koji/buildinfo?buildID=429792 You would need to recreate your instance because theme files are copied over to the instance during pkicreate. Ade On Wed, 2013-10-02 at 10:03 +0000, Oleg Antonenko wrote: > Hi there! > Are there any other suggestions regarding below? > > Many thanks, > Oleg > > -----Original Message----- > From: Jindrich Dolezal > Sent: 01 October 2013 14:14 > To: Taggart, Michelle > Cc: Oleg Antonenko; pki-users at redhat.com; Ciaran Bradley > Subject: Re: [Pki-users] pki-ca-9.0.3-30 setup > > hi, > there are some themes installed : > [root at jdrhel2 pki-ca]# rpm -qa | grep pki | grep theme ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-pki-common-theme-9.0.3-7.el6.noarch > > do we need some more themes? > > thanks > > jd > > On 10/01/2013 01:49 PM, Taggart, Michelle wrote: > > I believe you'll have to also install a theme. On the CentOS package, themes are not included. > > > > > > Thanks, > > > > Michelle T > > > > ----- Original Message ----- > > From: Oleg Antonenko > > To: pki-users at redhat.com > > Cc: Jindrich Dolezal , Ciaran > > Bradley > > Sent: Tue, 01 Oct 2013 07:08:38 -0400 (EDT) > > Subject: [Pki-users] pki-ca-9.0.3-30 setup > > > > Hello there! > > Could you help with the CA setup please? > > > > We installed a new machine with CentOS release 6.4 (Final) and installed the pki-ca-9.0.3-30 package. > > The command we used for creation was: > > > > pkicreate -pki_instance_root=/var/lib > > -pki_instance_name=pki-ca > > -subsystem_type=ca > > -agent_secure_port=9443 > > -ee_secure_port=9444 > > -ee_secure_client_auth_port=9446 > > -admin_secure_port=9445 > > -unsecure_port=9180 > > -tomcat_server_port=9701 > > -user=pkiuser > > -group=pkiuser > > -redirect conf=/etc/pki-ca > > -redirect logs=/var/log/pki-ca > > -verbose > > > > After clicking through the wizard and restarting the service: > > > > status: > > [root at jdrhel2 ~]# /sbin/service pki-cad status pki-ca pki-ca (pid > > 4988) is running... [ OK ] > > Unsecure Port = http://jdrhel2:9180/ca/ee/ca > > Secure Agent Port = https://jdrhel2:9443/ca/agent/ca > > Secure EE Port = https://jdrhel2:9444/ca/ee/ca > > Secure Admin Port = https://jdrhel2:9445/ca/services > > EE Client Auth Port = https://jdrhel2:9446/ca/eeca/ca > > PKI Console Port = pkiconsole https://jdrhel2:9445/ca > > Tomcat Port = 9701 (for shutdown) > > > > PKI Instance Name: pki-ca > > PKI Subsystem Type: Root CA (Security Domain) > > > > Registered PKI Security Domain Information: > > ========================================================================== > > Name: AMSDomain > > URL: https://jdrhel2:9445 > > ====================================================================== > > ==== > > > > Everything seems to be running, but when i connect to the adresses above, i can see firefox is verifying server certificate, uses personal certificate, but then the page is empty. > > To be precise, there are just two links leading to empty pages: > > - link 'SSL End Users Services' pointing at https://jdrhel2:9444/ca/ee/ca and > > - link 'Agent Services' pointing at https://jdrhel2:9443/ca/agent/ca > > > > Is there anything we did wrong or forgot to configure? > > > > Many thanks, > > Oleg > > > > > > > > > > > > > > > > _______________________________________________ > > 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 WilliamC.Elliott at s-itsolutions.at Wed Oct 2 18:26:23 2013 From: WilliamC.Elliott at s-itsolutions.at (Elliott William C OSS sIT) Date: Wed, 2 Oct 2013 18:26:23 +0000 Subject: [Pki-users] base64 CMC Request format Message-ID: <85C87A9995875247B2DD471950E0AE4D1B5BAE40@M0182.s-mxs.net> Hi all, Can Dogtag (in this case v. 9.0.3-30.el6 ) be coerced into accepting base64-encoded CMC requests? Is there a parameter somewhere? Or would it require reprogramming? We have a (smart-)card management system (runs under Windows) which sends the requests and expects the responses to both be base64 encoded. Thanks and best regards, William Elliott s IT Solutions Open System Services From awnuk at redhat.com Wed Oct 2 19:07:08 2013 From: awnuk at redhat.com (Andrew Wnuk) Date: Wed, 02 Oct 2013 12:07:08 -0700 Subject: [Pki-users] base64 CMC Request format In-Reply-To: <85C87A9995875247B2DD471950E0AE4D1B5BAE40@M0182.s-mxs.net> References: <85C87A9995875247B2DD471950E0AE4D1B5BAE40@M0182.s-mxs.net> Message-ID: <524C6EDC.6010908@redhat.com> On 10/02/2013 11:26 AM, Elliott William C OSS sIT wrote: > Hi all, > > Can Dogtag (in this case v. 9.0.3-30.el6 ) be coerced into accepting base64-encoded CMC requests? Is there a parameter somewhere? Or would it require reprogramming? > > We have a (smart-)card management system (runs under Windows) which sends the requests and expects the responses to both be base64 encoded. > > Thanks and best regards, > > William Elliott > s IT Solutions > Open System Services > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users Check profiles/ca/caCMCUserCert.cfg profile. You may also check https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/CertProfileReference.html#CMC_Certificate_Request_Input and https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Setting_up_CMC_Enrollment.html Andrew From WilliamC.Elliott at s-itsolutions.at Thu Oct 3 06:47:30 2013 From: WilliamC.Elliott at s-itsolutions.at (Elliott William C OSS sIT) Date: Thu, 3 Oct 2013 06:47:30 +0000 Subject: [Pki-users] base64 CMC Request format In-Reply-To: <524C6EDC.6010908@redhat.com> References: <85C87A9995875247B2DD471950E0AE4D1B5BAE40@M0182.s-mxs.net> <524C6EDC.6010908@redhat.com> Message-ID: <85C87A9995875247B2DD471950E0AE4D1B5BEE4F@M0182.s-mxs.net> We already use CMC enrollment (using profile caFullCMCUserCert) remotely from a RedHat system. It works without a hitch. It requires (ala Docu) converting the requests to binary format with AtoB before sending them on with HttpClient to the CMC servlet (/ca/ee/ca/profileSubmitCMCFull), and then receiving the (binary-encoded) response. When the card management system under windows sends a request - it is base64-encoded. The CA cannot parse it and the authentication fails: [02/Oct/2013:14:03:26][http-9543-3]: SignedAuditEventFactory: create() message=[AuditEvent=CMC_SIGNED_REQUEST_SIG_VERIFY][SubjectID=$NonRoleUser$][Outcome=Failure][ReqType=$Unidentified$][CertSubject=$Unidentified$][SignerInfo=$Unidentified$] agent pre-approved CMC request signature verification Best regards, Bill Elliott -----Urspr?ngliche Nachricht----- Von: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] Im Auftrag von Andrew Wnuk Gesendet: Mittwoch, 02. Oktober 2013 21:07 An: pki-users at redhat.com Betreff: Re: [Pki-users] base64 CMC Request format [heur] On 10/02/2013 11:26 AM, Elliott William C OSS sIT wrote: > Hi all, > > Can Dogtag (in this case v. 9.0.3-30.el6 ) be coerced into accepting base64-encoded CMC requests? Is there a parameter somewhere? Or would it require reprogramming? > > We have a (smart-)card management system (runs under Windows) which sends the requests and expects the responses to both be base64 encoded. > > Thanks and best regards, > > William Elliott > s IT Solutions > Open System Services > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users Check profiles/ca/caCMCUserCert.cfg profile. You may also check https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/CertProfileReference.html#CMC_Certificate_Request_Input and https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Setting_up_CMC_Enrollment.html Andrew _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users From Oleg.Antonenko at adaptivemobile.com Thu Oct 3 10:56:26 2013 From: Oleg.Antonenko at adaptivemobile.com (Oleg Antonenko) Date: Thu, 3 Oct 2013 10:56:26 +0000 Subject: [Pki-users] pki-ca-9.0.3-30 setup In-Reply-To: <1380722165.2503.5.camel@localhost.localdomain> References: <1193695098.31145.1380628189114.JavaMail.root@mail02.philasd.org> <524ACA87.3060009@adaptivemobile.com> <34A5A0661B86944184C25952A4F169908691FD57@Exchange-AMS.adaptivemobile.com> <1380722165.2503.5.camel@localhost.localdomain> Message-ID: <34A5A0661B86944184C25952A4F169908691FFD9@Exchange-AMS.adaptivemobile.com> Hi Ade, That worked. Thanks a mil for your help! Regards, Oleg -----Original Message----- From: Ade Lee [mailto:alee at redhat.com] Sent: 02 October 2013 14:56 To: Oleg Antonenko Cc: Jindrich Dolezal; Taggart, Michelle; Ciaran Bradley; pki-users at redhat.com Subject: Re: [Pki-users] pki-ca-9.0.3-30 setup The ipa-pki-ca-theme is a very crippled version of the real theme. Basically, dogtag 9 is in RHEL6 and hence, Centos 6, to support IPA, which does not use a UI to interact with the CA. I would install the dogtag-pki-theme package from fedora 17 -- http://koji.fedoraproject.org/koji/buildinfo?buildID=429792 You would need to recreate your instance because theme files are copied over to the instance during pkicreate. Ade On Wed, 2013-10-02 at 10:03 +0000, Oleg Antonenko wrote: > Hi there! > Are there any other suggestions regarding below? > > Many thanks, > Oleg > > -----Original Message----- > From: Jindrich Dolezal > Sent: 01 October 2013 14:14 > To: Taggart, Michelle > Cc: Oleg Antonenko; pki-users at redhat.com; Ciaran Bradley > Subject: Re: [Pki-users] pki-ca-9.0.3-30 setup > > hi, > there are some themes installed : > [root at jdrhel2 pki-ca]# rpm -qa | grep pki | grep theme > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-pki-common-theme-9.0.3-7.el6.noarch > > do we need some more themes? > > thanks > > jd > > On 10/01/2013 01:49 PM, Taggart, Michelle wrote: > > I believe you'll have to also install a theme. On the CentOS package, themes are not included. > > > > > > Thanks, > > > > Michelle T > > > > ----- Original Message ----- > > From: Oleg Antonenko > > To: pki-users at redhat.com > > Cc: Jindrich Dolezal , Ciaran > > Bradley > > Sent: Tue, 01 Oct 2013 07:08:38 -0400 (EDT) > > Subject: [Pki-users] pki-ca-9.0.3-30 setup > > > > Hello there! > > Could you help with the CA setup please? > > > > We installed a new machine with CentOS release 6.4 (Final) and installed the pki-ca-9.0.3-30 package. > > The command we used for creation was: > > > > pkicreate -pki_instance_root=/var/lib > > -pki_instance_name=pki-ca > > -subsystem_type=ca > > -agent_secure_port=9443 > > -ee_secure_port=9444 > > -ee_secure_client_auth_port=9446 > > -admin_secure_port=9445 > > -unsecure_port=9180 > > -tomcat_server_port=9701 > > -user=pkiuser > > -group=pkiuser > > -redirect conf=/etc/pki-ca > > -redirect logs=/var/log/pki-ca > > -verbose > > > > After clicking through the wizard and restarting the service: > > > > status: > > [root at jdrhel2 ~]# /sbin/service pki-cad status pki-ca pki-ca (pid > > 4988) is running... [ OK ] > > Unsecure Port = http://jdrhel2:9180/ca/ee/ca > > Secure Agent Port = https://jdrhel2:9443/ca/agent/ca > > Secure EE Port = https://jdrhel2:9444/ca/ee/ca > > Secure Admin Port = https://jdrhel2:9445/ca/services > > EE Client Auth Port = https://jdrhel2:9446/ca/eeca/ca > > PKI Console Port = pkiconsole https://jdrhel2:9445/ca > > Tomcat Port = 9701 (for shutdown) > > > > PKI Instance Name: pki-ca > > PKI Subsystem Type: Root CA (Security Domain) > > > > Registered PKI Security Domain Information: > > ========================================================================== > > Name: AMSDomain > > URL: https://jdrhel2:9445 > > ==================================================================== > > == > > ==== > > > > Everything seems to be running, but when i connect to the adresses above, i can see firefox is verifying server certificate, uses personal certificate, but then the page is empty. > > To be precise, there are just two links leading to empty pages: > > - link 'SSL End Users Services' pointing at https://jdrhel2:9444/ca/ee/ca and > > - link 'Agent Services' pointing at > > https://jdrhel2:9443/ca/agent/ca > > > > Is there anything we did wrong or forgot to configure? > > > > Many thanks, > > Oleg > > > > > > > > > > > > > > > > _______________________________________________ > > 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 Richard.Thomas at the-logic-group.com Thu Oct 3 15:49:46 2013 From: Richard.Thomas at the-logic-group.com (Richard Thomas) Date: Thu, 3 Oct 2013 16:49:46 +0100 Subject: [Pki-users] CA Administrator of Instance pki-ca Message-ID: <574459158D85E14CBBA091C8AD9B44E27B34EFEECF@ms03.GS.TLG.PRIVATE> Hi all, I hope someone would be able to help me with this. I have taken over a Dog Tag system and I have little knowledge of it. I need to renew the "CA Administrator of Instance pki-ca" certificate, as it is running out in a few weeks. Would someone be able to point me in the direction of any documentation on how to do this or let me know how to do it. I would massively appreciate any guidance on this. Thanks in advance, Richard. The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From awnuk at redhat.com Thu Oct 3 17:05:50 2013 From: awnuk at redhat.com (Andrew Wnuk) Date: Thu, 03 Oct 2013 10:05:50 -0700 Subject: [Pki-users] CA Administrator of Instance pki-ca In-Reply-To: <574459158D85E14CBBA091C8AD9B44E27B34EFEECF@ms03.GS.TLG.PRIVATE> References: <574459158D85E14CBBA091C8AD9B44E27B34EFEECF@ms03.GS.TLG.PRIVATE> Message-ID: <524DA3EE.3080605@redhat.com> Hi Richard, You can renew certificate using: https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/renewing-certificates.html and then add new certificate to CA administrator entry using console. Best, Andrew On 10/03/2013 08:49 AM, Richard Thomas wrote: > Hi all, > I hope someone would be able to help me with this. > I have taken over a Dog Tag system and I have little knowledge of it. > I need to renew the "CA Administrator of Instance pki-ca" certificate, > as it is running out in a few weeks. > Would someone be able to point me in the direction of any > documentation on how to do this or let me know how to do it. > I would massively appreciate any guidance on this. > Thanks in advance, > Richard. > *The world's first PCI accreditation for a Point to Point Encryption > application.* _*Find out more...*_ > > The Logic Group > Enterprises Limited > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom phone > fax > email > web +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com Registered > in England > Number 2609323 > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business > Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered > No. 2609323 > > The information in this email and any attachments are confidential and > may be legally privileged and protected by law. It is for the intended > recipient only. If you are not the intended recipient you may not use, > disclose, copy, distribute, print or rely on the content of this email > or its attachments. If this email has been received by you in error > please advise the sender and delete the email from your system. > > > > > _______________________________________________ > 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 cfu at redhat.com Thu Oct 3 21:24:43 2013 From: cfu at redhat.com (Christina Fu) Date: Thu, 03 Oct 2013 14:24:43 -0700 Subject: [Pki-users] base64 CMC Request format In-Reply-To: <85C87A9995875247B2DD471950E0AE4D1B5BEE4F@M0182.s-mxs.net> References: <85C87A9995875247B2DD471950E0AE4D1B5BAE40@M0182.s-mxs.net> <524C6EDC.6010908@redhat.com> <85C87A9995875247B2DD471950E0AE4D1B5BEE4F@M0182.s-mxs.net> Message-ID: <524DE09B.1010806@redhat.com> Hi Bill, Yes the profileSubmitCMCFull servlet only takes and responds in binary. However, the profileSubmit servlet does take base64 encoded requests (see the caCMCUserCert prfoile from the ee page). Which means, technically, it can be done, though may not be straight-forward at first glance. Here is what you can do (I just tried it and it works for me): 1. take your Base64-encoded CMC request blob and URL encode it. 2. create a file, say sendCMCreq.txt, which contains the following data: profileId=caCMCUserCert&cert_request_type=cmc&cert_request= e.g. my sendCMCreq.txt reads: profileId=caCMCUserCert&cert_request_type=cmc&cert_request=MIILqAYJKoZIhvcNAQ... 3. run the following: wget --post-file sendCMCreq.txt http:///ca/ee/ca/profileSubmit 4. Once you get the successsful response (in HTML), glean for outputList.outputVal=xxx The "xxx" is your b64 encoded certificate. It's formatted for display so you might want to further process it. Hope this helps. Christina On 10/02/2013 11:47 PM, Elliott William C OSS sIT wrote: > We already use CMC enrollment (using profile caFullCMCUserCert) remotely from a RedHat system. It works without a hitch. It requires (ala Docu) converting the requests to binary format with AtoB before sending them on with HttpClient to the CMC servlet (/ca/ee/ca/profileSubmitCMCFull), and then receiving the (binary-encoded) response. > > When the card management system under windows sends a request - it is base64-encoded. The CA cannot parse it and the authentication fails: > > [02/Oct/2013:14:03:26][http-9543-3]: SignedAuditEventFactory: create() message=[AuditEvent=CMC_SIGNED_REQUEST_SIG_VERIFY][SubjectID=$NonRoleUser$][Outcome=Failure][ReqType=$Unidentified$][CertSubject=$Unidentified$][SignerInfo=$Unidentified$] agent pre-approved CMC request signature verification > > Best regards, > Bill Elliott > > -----Urspr?ngliche Nachricht----- > Von: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] Im Auftrag von Andrew Wnuk > Gesendet: Mittwoch, 02. Oktober 2013 21:07 > An: pki-users at redhat.com > Betreff: Re: [Pki-users] base64 CMC Request format [heur] > > On 10/02/2013 11:26 AM, Elliott William C OSS sIT wrote: >> Hi all, >> >> Can Dogtag (in this case v. 9.0.3-30.el6 ) be coerced into accepting base64-encoded CMC requests? Is there a parameter somewhere? Or would it require reprogramming? >> >> We have a (smart-)card management system (runs under Windows) which sends the requests and expects the responses to both be base64 encoded. >> >> Thanks and best regards, >> >> William Elliott >> s IT Solutions >> Open System Services >> >> >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > Check profiles/ca/caCMCUserCert.cfg profile. > You may also check > https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/CertProfileReference.html#CMC_Certificate_Request_Input > and > https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Setting_up_CMC_Enrollment.html > > Andrew > > _______________________________________________ > 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 WilliamC.Elliott at s-itsolutions.at Fri Oct 4 10:08:06 2013 From: WilliamC.Elliott at s-itsolutions.at (Elliott William C OSS sIT) Date: Fri, 4 Oct 2013 10:08:06 +0000 Subject: [Pki-users] base64 CMC Request format In-Reply-To: <524DE09B.1010806@redhat.com> References: <85C87A9995875247B2DD471950E0AE4D1B5BAE40@M0182.s-mxs.net> <524C6EDC.6010908@redhat.com> <85C87A9995875247B2DD471950E0AE4D1B5BEE4F@M0182.s-mxs.net> <524DE09B.1010806@redhat.com> Message-ID: <85C87A9995875247B2DD471950E0AE4D1B5C3F09@M0182.s-mxs.net> Hello Christina, Many thanks for the idea. We'll try it out. Best regards, Bill Elliott -----Urspr?ngliche Nachricht----- Von: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] Im Auftrag von Christina Fu Gesendet: Donnerstag, 03. Oktober 2013 23:25 An: pki-users at redhat.com Betreff: Re: [Pki-users] base64 CMC Request format [bayes][heur] Hi Bill, Yes the profileSubmitCMCFull servlet only takes and responds in binary. However, the profileSubmit servlet does take base64 encoded requests (see the caCMCUserCert prfoile from the ee page). Which means, technically, it can be done, though may not be straight-forward at first glance. Here is what you can do (I just tried it and it works for me): 1. take your Base64-encoded CMC request blob and URL encode it. 2. create a file, say sendCMCreq.txt, which contains the following data: profileId=caCMCUserCert&cert_request_type=cmc&cert_request= e.g. my sendCMCreq.txt reads: profileId=caCMCUserCert&cert_request_type=cmc&cert_request=MIILqAYJKoZIhvcNAQ... 3. run the following: wget --post-file sendCMCreq.txt http:///ca/ee/ca/profileSubmit 4. Once you get the successsful response (in HTML), glean for outputList.outputVal=xxx The "xxx" is your b64 encoded certificate. It's formatted for display so you might want to further process it. Hope this helps. Christina On 10/02/2013 11:47 PM, Elliott William C OSS sIT wrote: > We already use CMC enrollment (using profile caFullCMCUserCert) remotely from a RedHat system. It works without a hitch. It requires (ala Docu) converting the requests to binary format with AtoB before sending them on with HttpClient to the CMC servlet (/ca/ee/ca/profileSubmitCMCFull), and then receiving the (binary-encoded) response. > > When the card management system under windows sends a request - it is base64-encoded. The CA cannot parse it and the authentication fails: > > [02/Oct/2013:14:03:26][http-9543-3]: SignedAuditEventFactory: create() message=[AuditEvent=CMC_SIGNED_REQUEST_SIG_VERIFY][SubjectID=$NonRoleUser$][Outcome=Failure][ReqType=$Unidentified$][CertSubject=$Unidentified$][SignerInfo=$Unidentified$] agent pre-approved CMC request signature verification > > Best regards, > Bill Elliott > > -----Urspr?ngliche Nachricht----- > Von: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] Im Auftrag von Andrew Wnuk > Gesendet: Mittwoch, 02. Oktober 2013 21:07 > An: pki-users at redhat.com > Betreff: Re: [Pki-users] base64 CMC Request format [heur] > > On 10/02/2013 11:26 AM, Elliott William C OSS sIT wrote: >> Hi all, >> >> Can Dogtag (in this case v. 9.0.3-30.el6 ) be coerced into accepting base64-encoded CMC requests? Is there a parameter somewhere? Or would it require reprogramming? >> >> We have a (smart-)card management system (runs under Windows) which sends the requests and expects the responses to both be base64 encoded. >> >> Thanks and best regards, >> >> William Elliott >> s IT Solutions >> Open System Services >> >> >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > Check profiles/ca/caCMCUserCert.cfg profile. > You may also check > https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/CertProfileReference.html#CMC_Certificate_Request_Input > and > https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Setting_up_CMC_Enrollment.html > > Andrew > > _______________________________________________ > 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 _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users From Oleg.Antonenko at adaptivemobile.com Fri Oct 4 15:08:03 2013 From: Oleg.Antonenko at adaptivemobile.com (Oleg Antonenko) Date: Fri, 4 Oct 2013 15:08:03 +0000 Subject: [Pki-users] will the new version of RHCS support RHEL6? In-Reply-To: <5245D666.8030508@redhat.com> References: <5245D666.8030508@redhat.com> Message-ID: <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> Hi Nathan, Could you please shed some light on the future plans for the pki-ca portion of RHEL? Will it be included in the standard RHEL distribution in the future? I?m asking because we?re planning to use the CA bit only for issuing certificates to mobile devices via SCEP. We do not require any other services or the full blown IPA? With thanks, Oleg From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Nathan Kinder Sent: 27 September 2013 20:03 To: pki-users at redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 09/26/2013 10:25 PM, ?? wrote: Hi all, I'm a beginner of the dogtag certificate system, dogtag?RHCS?is a wonderful project, but I'm confused about RHCS, could you give any help? The latest version of RHCS is 8.1, which is based on dogtag 8.1, it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included without the other 5 subsystems, could you show me the consideration why RHCS do not support RHEL6? Is RHEL6 not secure enough or some other reasons? It was simply not a targeted platform (nor are there plans to release it there). The pki-ca portion is included for use by IdM (based on the FreeIPA project). Thanks, -NGK Regards. An Yang _______________________________________________ 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 dpal at redhat.com Fri Oct 4 15:21:00 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 04 Oct 2013 11:21:00 -0400 Subject: [Pki-users] will the new version of RHCS support RHEL6? In-Reply-To: <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> References: <5245D666.8030508@redhat.com> <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> Message-ID: <524EDCDC.9080802@redhat.com> On 10/04/2013 11:08 AM, Oleg Antonenko wrote: > > Hi Nathan, > > Could you please shed some light on the future plans for the pki-ca > portion of RHEL? > > Will it be included in the standard RHEL distribution in the future? > Dogtag 10+ will become a RHSC product on top of RHEL7.x Some of its portions will be gradually included into IPA that comes for free with RHEL. IMO full blown IPA is not that "full blown" in this case. We would be actually very interested if we can support this use case with core IPA. Would you be interested in a conversation about this? Thanks Dmitri > > > > I'm asking because we're planning to use the CA bit only for issuing > certificates to mobile devices via SCEP. We do not require any other > services or the full blown IPA... > > > > With thanks, > > Oleg > > > > *From:*pki-users-bounces at redhat.com > [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Nathan Kinder > *Sent:* 27 September 2013 20:03 > *To:* pki-users at redhat.com > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > > > On 09/26/2013 10:25 PM, ? ? wrote: > > Hi all, > > I'm a beginner of the dogtag certificate system, dogtag(RHCS)is a > wonderful project, but I'm confused about RHCS, could you give any > help? > > The latest version of RHCS is 8.1, which is based on dogtag 8.1, > it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included > without the other 5 subsystems, could you show me the > consideration why RHCS do not support RHEL6? > Is RHEL6 not secure enough or some other reasons? > > It was simply not a targeted platform (nor are there plans to release > it there). The pki-ca portion is included for use by IdM (based on > the FreeIPA project). > > Thanks, > -NGK > > > Regards. > An Yang > > > > _______________________________________________ > 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 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Fri Oct 4 15:29:45 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 04 Oct 2013 08:29:45 -0700 Subject: [Pki-users] will the new version of RHCS support RHEL6? In-Reply-To: <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> References: <5245D666.8030508@redhat.com> <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> Message-ID: <524EDEE9.2040301@redhat.com> On 10/04/2013 08:08 AM, Oleg Antonenko wrote: > > Hi Nathan, > > Could you please shed some light on the future plans for the pki-ca > portion of RHEL? > > Will it be included in the standard RHEL distribution in the future? > The CA potion is included in RHEL for use by IPA. There are no plans to change this. The CA portion in RHEL is not supported by Red Hat for standalone use without an entitlement for the rest of RHCS, which isn't available on RHEL 6 (but will be at some point in the future). Thanks, -NGK > > I?m asking because we?re planning to use the CA bit only for issuing > certificates to mobile devices via SCEP. We do not require any other > services or the full blown IPA? > > With thanks, > > Oleg > > *From:*pki-users-bounces at redhat.com > [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Nathan Kinder > *Sent:* 27 September 2013 20:03 > *To:* pki-users at redhat.com > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > On 09/26/2013 10:25 PM, ? ? wrote: > > Hi all, > > I'm a beginner of the dogtag certificate system, dogtag?RHCS?is > a wonderful project, but I'm confused about RHCS, could you give > any help? > > The latest version of RHCS is 8.1, which is based on dogtag 8.1, > it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included > without the other 5 subsystems, could you show me the > consideration why RHCS do not support RHEL6? > Is RHEL6 not secure enough or some other reasons? > > It was simply not a targeted platform (nor are there plans to release > it there). The pki-ca portion is included for use by IdM (based on the > FreeIPA project). > > Thanks, > -NGK > > > Regards. > An Yang > > > > _______________________________________________ > 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 Oleg.Antonenko at adaptivemobile.com Fri Oct 4 15:48:59 2013 From: Oleg.Antonenko at adaptivemobile.com (Oleg Antonenko) Date: Fri, 4 Oct 2013 15:48:59 +0000 Subject: [Pki-users] will the new version of RHCS support RHEL6? In-Reply-To: <524EDCDC.9080802@redhat.com> References: <5245D666.8030508@redhat.com> <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> <524EDCDC.9080802@redhat.com> Message-ID: <34A5A0661B86944184C25952A4F16990869204E7@Exchange-AMS.adaptivemobile.com> Hi Dmitri, Nathan, Thank you for speedy responses. Could you please confirm my understanding? - RHCS is going to be shipped as a part of RHEL7.x in the foreseeable future; - IPA is a free part of RHEL 6.x and will remain as such in the foreseeable future; - RHEL 6.x does not ship RHCS, but includes only pki-ca packages in order to support IPA. Could you also clarify your point here ? The CA portion in RHEL is not supported by Red Hat for standalone use without an entitlement for the rest of RHCS, which isn't available on RHEL 6 Does it mean RHCS is not free? Regarding this - We would be actually very interested if we can support this use case with core IPA. Would you be interested in a conversation about this? Yes, we?d love to. Many thanks, Oleg From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: 04 October 2013 16:21 To: pki-users at redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/04/2013 11:08 AM, Oleg Antonenko wrote: Hi Nathan, Could you please shed some light on the future plans for the pki-ca portion of RHEL? Will it be included in the standard RHEL distribution in the future? Dogtag 10+ will become a RHSC product on top of RHEL7.x Some of its portions will be gradually included into IPA that comes for free with RHEL. IMO full blown IPA is not that "full blown" in this case. We would be actually very interested if we can support this use case with core IPA. Would you be interested in a conversation about this? Thanks Dmitri I?m asking because we?re planning to use the CA bit only for issuing certificates to mobile devices via SCEP. We do not require any other services or the full blown IPA? With thanks, Oleg From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Nathan Kinder Sent: 27 September 2013 20:03 To: pki-users at redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 09/26/2013 10:25 PM, ? ? wrote: Hi all, I'm a beginner of the dogtag certificate system, dogtag?RHCS?is a wonderful project, but I'm confused about RHCS, could you give any help? The latest version of RHCS is 8.1, which is based on dogtag 8.1, it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included without the other 5 subsystems, could you show me the consideration why RHCS do not support RHEL6? Is RHEL6 not secure enough or some other reasons? It was simply not a targeted platform (nor are there plans to release it there). The pki-ca portion is included for use by IdM (based on the FreeIPA project). Thanks, -NGK Regards. An Yang _______________________________________________ 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 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Oct 4 15:54:26 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 04 Oct 2013 11:54:26 -0400 Subject: [Pki-users] will the new version of RHCS support RHEL6? In-Reply-To: <34A5A0661B86944184C25952A4F16990869204E7@Exchange-AMS.adaptivemobile.com> References: <5245D666.8030508@redhat.com> <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> <524EDCDC.9080802@redhat.com> <34A5A0661B86944184C25952A4F16990869204E7@Exchange-AMS.adaptivemobile.com> Message-ID: <524EE4B2.1010901@redhat.com> On 10/04/2013 11:48 AM, Oleg Antonenko wrote: > > Hi Dmitri, Nathan, > > Thank you for speedy responses. > > Could you please confirm my understanding? > > -RHCS is going to be shipped as a part of RHEL7.x in the foreseeable > future; > It is not "a part" it is a stand alone product and not free. > -IPA is a free part of RHEL 6.x and will remain as such in the > foreseeable future; > Correct and same is true for RHEL7.x > -RHEL 6.x does not ship RHCS, but includes only pki-ca packages in > order to support IPA. > Correct > Could you also clarify your point here ? > > /The CA portion in RHEL is not supported by Red Hat for standalone use > /*/without an entitlement for the rest of RHCS/*/, which isn't > available on RHEL 6/// > RHCS is a layered product and can be acquired separately. We do not ship a version of RHCS on top of RHEL6. It is a big product and takes a lot of time to deliver. We decided to skip a major RHEL version. > Does it mean RHCS is not free? > Correct. > > Regarding this - > > /We would be actually very interested if we can support this use case > with core IPA. > Would you be interested in a conversation about this? > > /// > > Yes, we?d love to. > Ok let us have one. I am sorry, I have not been following the whole thread, just this mail caught my eye so what kind of functionality we are looking for? Can you formulate a "wish list" for your use case assuming the CA is a part of IPA? > Many thanks, > > Oleg > > *From:*pki-users-bounces at redhat.com > [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* 04 October 2013 16:21 > *To:* pki-users at redhat.com > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > On 10/04/2013 11:08 AM, Oleg Antonenko wrote: > > Hi Nathan, > > Could you please shed some light on the future plans for the pki-ca > portion of RHEL? > > Will it be included in the standard RHEL distribution in the future? > > > Dogtag 10+ will become a RHSC product on top of RHEL7.x > > Some of its portions will be gradually included into IPA that comes > for free with RHEL. > IMO full blown IPA is not that "full blown" in this case. > > We would be actually very interested if we can support this use case > with core IPA. > Would you be interested in a conversation about this? > > Thanks > Dmitri > > > I?m asking because we?re planning to use the CA bit only for issuing > certificates to mobile devices via SCEP. We do not require any other > services or the full blown IPA? > > With thanks, > > Oleg > > *From:*pki-users-bounces at redhat.com > > [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Nathan Kinder > *Sent:* 27 September 2013 20:03 > *To:* pki-users at redhat.com > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > On 09/26/2013 10:25 PM, ? ? wrote: > > Hi all, > > I'm a beginner of the dogtag certificate system, dogtag?RHCS?is > a wonderful project, but I'm confused about RHCS, could you give > any help? > > The latest version of RHCS is 8.1, which is based on dogtag 8.1, > it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included > without the other 5 subsystems, could you show me the > consideration why RHCS do not support RHEL6? > Is RHEL6 not secure enough or some other reasons? > > It was simply not a targeted platform (nor are there plans to release > it there). The pki-ca portion is included for use by IdM (based on the > FreeIPA project). > > Thanks, > -NGK > > > > Regards. > An Yang > > > > > _______________________________________________ > 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 > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Oleg.Antonenko at adaptivemobile.com Fri Oct 4 16:12:48 2013 From: Oleg.Antonenko at adaptivemobile.com (Oleg Antonenko) Date: Fri, 4 Oct 2013 16:12:48 +0000 Subject: [Pki-users] will the new version of RHCS support RHEL6? In-Reply-To: <524EE4B2.1010901@redhat.com> References: <5245D666.8030508@redhat.com> <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> <524EDCDC.9080802@redhat.com> <34A5A0661B86944184C25952A4F16990869204E7@Exchange-AMS.adaptivemobile.com> <524EE4B2.1010901@redhat.com> Message-ID: <34A5A0661B86944184C25952A4F1699086920502@Exchange-AMS.adaptivemobile.com> That?s all clear now, thank you Dmitri! Regarding our wish list :) Basically we just have evaluated ejbCA, so we want something similar but without EJB and heavy weight app server? i.e. - * UI for managing certs * Support SCEP & OCSP * API for issuing and revoking certs (cert-based request auth is preferrable) - as we want to integrate out product for revoking certs * Desirable - Export a key store (including cert) as PKCS#12, PEM (for manual deployment of certs on e.g. SSL servers). As mentioned earlier we are planning to use a CA for issuing and delivering certs to mobile devices via SCEP. So far we managed to issue certs for iphones via SCEP in ejbCA and Dogtag (pki-ca 9.0.3-30 package). Dogtag wins provided we can carry on using standalone CA services in the future for free as a part of RHEL IPA? Thanks, Oleg From: Dmitri Pal [mailto:dpal at redhat.com] Sent: 04 October 2013 16:54 To: Oleg Antonenko Cc: Nathan Kinder (nkinder at redhat.com); Ciaran Bradley; pki-users at redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/04/2013 11:48 AM, Oleg Antonenko wrote: Hi Dmitri, Nathan, Thank you for speedy responses. Could you please confirm my understanding? RHCS is going to be shipped as a part of RHEL7.x in the foreseeable future; It is not "a part" it is a stand alone product and not free. IPA is a free part of RHEL 6.x and will remain as such in the foreseeable future; Correct and same is true for RHEL7.x RHEL 6.x does not ship RHCS, but includes only pki-ca packages in order to support IPA. Correct Could you also clarify your point here ? The CA portion in RHEL is not supported by Red Hat for standalone use without an entitlement for the rest of RHCS, which isn't available on RHEL 6 RHCS is a layered product and can be acquired separately. We do not ship a version of RHCS on top of RHEL6. It is a big product and takes a lot of time to deliver. We decided to skip a major RHEL version. Does it mean RHCS is not free? Correct. Regarding this - We would be actually very interested if we can support this use case with core IPA. Would you be interested in a conversation about this? Yes, we?d love to. Ok let us have one. I am sorry, I have not been following the whole thread, just this mail caught my eye so what kind of functionality we are looking for? Can you formulate a "wish list" for your use case assuming the CA is a part of IPA? Many thanks, Oleg From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: 04 October 2013 16:21 To: pki-users at redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/04/2013 11:08 AM, Oleg Antonenko wrote: Hi Nathan, Could you please shed some light on the future plans for the pki-ca portion of RHEL? Will it be included in the standard RHEL distribution in the future? Dogtag 10+ will become a RHSC product on top of RHEL7.x Some of its portions will be gradually included into IPA that comes for free with RHEL. IMO full blown IPA is not that "full blown" in this case. We would be actually very interested if we can support this use case with core IPA. Would you be interested in a conversation about this? Thanks Dmitri I?m asking because we?re planning to use the CA bit only for issuing certificates to mobile devices via SCEP. We do not require any other services or the full blown IPA? With thanks, Oleg From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Nathan Kinder Sent: 27 September 2013 20:03 To: pki-users at redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 09/26/2013 10:25 PM, ? ? wrote: Hi all, I'm a beginner of the dogtag certificate system, dogtag?RHCS?is a wonderful project, but I'm confused about RHCS, could you give any help? The latest version of RHCS is 8.1, which is based on dogtag 8.1, it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included without the other 5 subsystems, could you show me the consideration why RHCS do not support RHEL6? Is RHEL6 not secure enough or some other reasons? It was simply not a targeted platform (nor are there plans to release it there). The pki-ca portion is included for use by IdM (based on the FreeIPA project). Thanks, -NGK Regards. An Yang _______________________________________________ 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 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Oct 4 17:44:04 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 04 Oct 2013 13:44:04 -0400 Subject: [Pki-users] will the new version of RHCS support RHEL6? In-Reply-To: <34A5A0661B86944184C25952A4F1699086920502@Exchange-AMS.adaptivemobile.com> References: <5245D666.8030508@redhat.com> <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> <524EDCDC.9080802@redhat.com> <34A5A0661B86944184C25952A4F16990869204E7@Exchange-AMS.adaptivemobile.com> <524EE4B2.1010901@redhat.com> <34A5A0661B86944184C25952A4F1699086920502@Exchange-AMS.adaptivemobile.com> Message-ID: <524EFE64.3090803@redhat.com> On 10/04/2013 12:12 PM, Oleg Antonenko wrote: > > That?s all clear now, thank you Dmitri! > > Regarding our wish list J > > Basically we just have evaluated ejbCA, so we want something similar > but without EJB and heavy weight app server? i.e. - > > ?UI for managing certs > Can you define workflows and actors? Who does what when to the certs? Are certs associated to users or to devices? Do you track devices in the CA or somewhere else? Are users enterprise users (belong to one company) or internet users (any user from the street)? > ?Support SCEP & OCSP > Dogtag supports both. First as a protocol the second one is the component that can be installed and turned on. For SCEP do you actually need a SCEP client ? What do you use a SEP client? Are there any specific features of the SCEP protocol that are required that are currently natively not supported by the Dogtag CA? > ?API for issuing and revoking certs (cert-based request auth is > preferrable) -- as we want to integrate out product for revoking certs > The product can be given a keytab and authenticate kerberos to the IPA. It is very simple and would be easier to accomplish. API for managing serts for hosts and services already available in IPA so the question is what the certs are associated with is very important. Also certmonger can be used for fetching certs and storing them in the files or DBs you need. Are you aware of certmonger? It can be effectively a whole alternative solution. From your portal you call Certmonger on the local system via CLI or D-BUS interface and it gets a cert for you. But I need to understand the workflow better. If you generate he PKI pair on you portal and deliver them to a device it is a perfect solution. If you use client side software on the mobile platform to send the signing request then it is a different workflow and you need to send such request to CA. > ?Desirable - Export a key store (including cert) as PKCS#12, PEM (for > manual deployment of certs on e.g. SSL servers). > When and where? During issuance or ability to later export it from the back end store? > As mentioned earlier we are planning to use a CA for issuing and > delivering certs to mobile devices via SCEP. > I am sorry I am not familiar with the details of the workflow in this case. Can you describe the chain of communication between mobile device, your portal and CA and what protocols used where? > So far we managed to issue certs for iphones via SCEP in ejbCA and > Dogtag (pki-ca 9.0.3-30 package). > > Dogtag wins provided we can carry on using standalone CA services in > the future for free as a part of RHEL IPA? > Yes this is a clear winner keeping in mind that we had some distant plans about the use case you are describing. Unfortunately we were not able to get a good understanding of the details of the use case in the past thus so many questions. Sorry. Thanks Dmitri > Thanks, > > Oleg > > *From:*Dmitri Pal [mailto:dpal at redhat.com] > *Sent:* 04 October 2013 16:54 > *To:* Oleg Antonenko > *Cc:* Nathan Kinder (nkinder at redhat.com); Ciaran Bradley; > pki-users at redhat.com > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > On 10/04/2013 11:48 AM, Oleg Antonenko wrote: > > Hi Dmitri, Nathan, > > Thank you for speedy responses. > > Could you please confirm my understanding? > > RHCS is going to be shipped as a part of RHEL7.x in the foreseeable > future; > > > It is not "a part" it is a stand alone product and not free. > > > IPA is a free part of RHEL 6.x and will remain as such in the > foreseeable future; > > > Correct and same is true for RHEL7.x > > > RHEL 6.x does not ship RHCS, but includes only pki-ca packages in > order to support IPA. > > > Correct > > > Could you also clarify your point here ? > > /The CA portion in RHEL is not supported by Red Hat for standalone use > /*/without an entitlement for the rest of RHCS/*/, which isn't > available on RHEL 6/ > > > RHCS is a layered product and can be acquired separately. > We do not ship a version of RHCS on top of RHEL6. It is a big product > and takes a lot of time to deliver. > We decided to skip a major RHEL version. > > > Does it mean RHCS is not free? > > > Correct. > > Regarding this - > > /We would be actually very interested if we can support this use case > with core IPA. > Would you be interested in a conversation about this? > > > / > > Yes, we?d love to. > > > Ok let us have one. > I am sorry, I have not been following the whole thread, just this mail > caught my eye so what kind of functionality we are looking for? > Can you formulate a "wish list" for your use case assuming the CA is a > part of IPA? > > > > Many thanks, > > Oleg > > *From:*pki-users-bounces at redhat.com > > [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* 04 October 2013 16:21 > *To:* pki-users at redhat.com > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > On 10/04/2013 11:08 AM, Oleg Antonenko wrote: > > Hi Nathan, > > Could you please shed some light on the future plans for the pki-ca > portion of RHEL? > > Will it be included in the standard RHEL distribution in the future? > > > Dogtag 10+ will become a RHSC product on top of RHEL7.x > > Some of its portions will be gradually included into IPA that comes > for free with RHEL. > IMO full blown IPA is not that "full blown" in this case. > > We would be actually very interested if we can support this use case > with core IPA. > Would you be interested in a conversation about this? > > Thanks > Dmitri > > > > I?m asking because we?re planning to use the CA bit only for issuing > certificates to mobile devices via SCEP. We do not require any other > services or the full blown IPA? > > With thanks, > > Oleg > > *From:*pki-users-bounces at redhat.com > > [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Nathan Kinder > *Sent:* 27 September 2013 20:03 > *To:* pki-users at redhat.com > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > On 09/26/2013 10:25 PM, ? ? wrote: > > Hi all, > > I'm a beginner of the dogtag certificate system, dogtag?RHCS?is > a wonderful project, but I'm confused about RHCS, could you give > any help? > > The latest version of RHCS is 8.1, which is based on dogtag 8.1, > it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included > without the other 5 subsystems, could you show me the > consideration why RHCS do not support RHEL6? > Is RHEL6 not secure enough or some other reasons? > > It was simply not a targeted platform (nor are there plans to release > it there). The pki-ca portion is included for use by IdM (based on the > FreeIPA project). > > Thanks, > -NGK > > > > > Regards. > An Yang > > > > > > _______________________________________________ > 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 > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Fri Oct 4 18:06:59 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 04 Oct 2013 11:06:59 -0700 Subject: [Pki-users] will the new version of RHCS support RHEL6? In-Reply-To: <524EFE64.3090803@redhat.com> References: <5245D666.8030508@redhat.com> <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> <524EDCDC.9080802@redhat.com> <34A5A0661B86944184C25952A4F16990869204E7@Exchange-AMS.adaptivemobile.com> <524EE4B2.1010901@redhat.com> <34A5A0661B86944184C25952A4F1699086920502@Exchange-AMS.adaptivemobile.com> <524EFE64.3090803@redhat.com> Message-ID: <524F03C3.4080209@redhat.com> On 10/04/2013 10:44 AM, Dmitri Pal wrote: > On 10/04/2013 12:12 PM, Oleg Antonenko wrote: >> >> That?s all clear now, thank you Dmitri! >> >> Regarding our wish list J >> >> Basically we just have evaluated ejbCA, so we want something similar >> but without EJB and heavy weight app server? i.e. - >> >> ?UI for managing certs >> > > Can you define workflows and actors? > Who does what when to the certs? > Are certs associated to users or to devices? > Do you track devices in the CA or somewhere else? > Are users enterprise users (belong to one company) or internet users > (any user from the street)? > >> ?Support SCEP & OCSP >> > > Dogtag supports both. First as a protocol the second one is the > component that can be installed and turned on. > For SCEP do you actually need a SCEP client ? What do you use a SEP > client? > Are there any specific features of the SCEP protocol that are required > that are currently natively not supported by the Dogtag CA? > >> ?API for issuing and revoking certs (cert-based request auth is >> preferrable) -- as we want to integrate out product for revoking certs >> > > The product can be given a keytab and authenticate kerberos to the > IPA. It is very simple and would be easier to accomplish. > API for managing serts for hosts and services already available in IPA > so the question is what the certs are associated with is very important. > Also certmonger can be used for fetching certs and storing them in the > files or DBs you need. > Are you aware of certmonger? > It can be effectively a whole alternative solution. From your portal > you call Certmonger on the local system via CLI or D-BUS interface and > it gets a cert for you. > But I need to understand the workflow better. If you generate he PKI > pair on you portal and deliver them to a device it is a perfect > solution. If you use client side software on the mobile platform to > send the signing request then it is a different workflow and you need > to send such request to CA. > >> ?Desirable - Export a key store (including cert) as PKCS#12, PEM (for >> manual deployment of certs on e.g. SSL servers). >> > > When and where? During issuance or ability to later export it from the > back end store? > >> As mentioned earlier we are planning to use a CA for issuing and >> delivering certs to mobile devices via SCEP. >> > > I am sorry I am not familiar with the details of the workflow in this > case. > Can you describe the chain of communication between mobile device, > your portal and CA and what protocols used where? iOS devices uses SCEP to enroll for certificates. The basic flow is that you have a "Profile Server", which is responsible for delivering a XML profile onto the authenticated iOS device. This XML profile contains details on how the iOS device should contact the CA via SCEP. When the profile is installed, the SCEP request is made and the returned certificate is installed. There is a good visual workflow of this process in this document: https://developer.apple.com/library/ios/documentation/networkinginternet/conceptual/iphoneotaconfiguration/OTASecurity/OTASecurity.html#//apple_ref/doc/uid/TP40009505-CH3-SW1 -NGK > >> So far we managed to issue certs for iphones via SCEP in ejbCA and >> Dogtag (pki-ca 9.0.3-30 package). >> >> Dogtag wins provided we can carry on using standalone CA services in >> the future for free as a part of RHEL IPA? >> > > Yes this is a clear winner keeping in mind that we had some distant > plans about the use case you are describing. Unfortunately we were not > able to get a good understanding of the details of the use case in the > past thus so many questions. Sorry. > > > Thanks > Dmitri > >> Thanks, >> >> Oleg >> >> *From:*Dmitri Pal [mailto:dpal at redhat.com] >> *Sent:* 04 October 2013 16:54 >> *To:* Oleg Antonenko >> *Cc:* Nathan Kinder (nkinder at redhat.com); Ciaran Bradley; >> pki-users at redhat.com >> *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? >> >> On 10/04/2013 11:48 AM, Oleg Antonenko wrote: >> >> Hi Dmitri, Nathan, >> >> Thank you for speedy responses. >> >> Could you please confirm my understanding? >> >> RHCS is going to be shipped as a part of RHEL7.x in the foreseeable >> future; >> >> >> It is not "a part" it is a stand alone product and not free. >> >> >> IPA is a free part of RHEL 6.x and will remain as such in the >> foreseeable future; >> >> >> Correct and same is true for RHEL7.x >> >> >> RHEL 6.x does not ship RHCS, but includes only pki-ca packages in >> order to support IPA. >> >> >> Correct >> >> >> Could you also clarify your point here ? >> >> /The CA portion in RHEL is not supported by Red Hat for standalone >> use /*/without an entitlement for the rest of RHCS/*/, which isn't >> available on RHEL 6/ >> >> >> RHCS is a layered product and can be acquired separately. >> We do not ship a version of RHCS on top of RHEL6. It is a big product >> and takes a lot of time to deliver. >> We decided to skip a major RHEL version. >> >> >> Does it mean RHCS is not free? >> >> >> Correct. >> >> Regarding this - >> >> /We would be actually very interested if we can support this use case >> with core IPA. >> Would you be interested in a conversation about this? >> >> >> / >> >> Yes, we?d love to. >> >> >> Ok let us have one. >> I am sorry, I have not been following the whole thread, just this >> mail caught my eye so what kind of functionality we are looking for? >> Can you formulate a "wish list" for your use case assuming the CA is >> a part of IPA? >> >> >> >> Many thanks, >> >> Oleg >> >> *From:*pki-users-bounces at redhat.com >> >> [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal >> *Sent:* 04 October 2013 16:21 >> *To:* pki-users at redhat.com >> *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? >> >> On 10/04/2013 11:08 AM, Oleg Antonenko wrote: >> >> Hi Nathan, >> >> Could you please shed some light on the future plans for the pki-ca >> portion of RHEL? >> >> Will it be included in the standard RHEL distribution in the future? >> >> >> Dogtag 10+ will become a RHSC product on top of RHEL7.x >> >> Some of its portions will be gradually included into IPA that comes >> for free with RHEL. >> IMO full blown IPA is not that "full blown" in this case. >> >> We would be actually very interested if we can support this use case >> with core IPA. >> Would you be interested in a conversation about this? >> >> Thanks >> Dmitri >> >> >> >> I?m asking because we?re planning to use the CA bit only for issuing >> certificates to mobile devices via SCEP. We do not require any other >> services or the full blown IPA? >> >> With thanks, >> >> Oleg >> >> *From:*pki-users-bounces at redhat.com >> >> [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Nathan Kinder >> *Sent:* 27 September 2013 20:03 >> *To:* pki-users at redhat.com >> *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? >> >> On 09/26/2013 10:25 PM, ? ? wrote: >> >> Hi all, >> >> I'm a beginner of the dogtag certificate system, dogtag?RHCS?is >> a wonderful project, but I'm confused about RHCS, could you give >> any help? >> >> The latest version of RHCS is 8.1, which is based on dogtag 8.1, >> it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included >> without the other 5 subsystems, could you show me the >> consideration why RHCS do not support RHEL6? >> Is RHEL6 not secure enough or some other reasons? >> >> It was simply not a targeted platform (nor are there plans to release >> it there). The pki-ca portion is included for use by IdM (based on >> the FreeIPA project). >> >> Thanks, >> -NGK >> >> >> >> >> Regards. >> An Yang >> >> >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Oct 4 18:37:48 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 04 Oct 2013 14:37:48 -0400 Subject: [Pki-users] will the new version of RHCS support RHEL6? In-Reply-To: <524F03C3.4080209@redhat.com> References: <5245D666.8030508@redhat.com> <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> <524EDCDC.9080802@redhat.com> <34A5A0661B86944184C25952A4F16990869204E7@Exchange-AMS.adaptivemobile.com> <524EE4B2.1010901@redhat.com> <34A5A0661B86944184C25952A4F1699086920502@Exchange-AMS.adaptivemobile.com> <524EFE64.3090803@redhat.com> <524F03C3.4080209@redhat.com> Message-ID: <524F0AFC.9020700@redhat.com> On 10/04/2013 02:06 PM, Nathan Kinder wrote: > On 10/04/2013 10:44 AM, Dmitri Pal wrote: >> On 10/04/2013 12:12 PM, Oleg Antonenko wrote: >>> >>> That?s all clear now, thank you Dmitri! >>> >>> Regarding our wish list J >>> >>> Basically we just have evaluated ejbCA, so we want something similar >>> but without EJB and heavy weight app server? i.e. - >>> >>> ?UI for managing certs >>> >> >> Can you define workflows and actors? >> Who does what when to the certs? >> Are certs associated to users or to devices? >> Do you track devices in the CA or somewhere else? >> Are users enterprise users (belong to one company) or internet users >> (any user from the street)? >> >>> ?Support SCEP & OCSP >>> >> >> Dogtag supports both. First as a protocol the second one is the >> component that can be installed and turned on. >> For SCEP do you actually need a SCEP client ? What do you use a SEP >> client? >> Are there any specific features of the SCEP protocol that are >> required that are currently natively not supported by the Dogtag CA? >> >>> ?API for issuing and revoking certs (cert-based request auth is >>> preferrable) -- as we want to integrate out product for revoking certs >>> >> >> The product can be given a keytab and authenticate kerberos to the >> IPA. It is very simple and would be easier to accomplish. >> API for managing serts for hosts and services already available in >> IPA so the question is what the certs are associated with is very >> important. >> Also certmonger can be used for fetching certs and storing them in >> the files or DBs you need. >> Are you aware of certmonger? >> It can be effectively a whole alternative solution. From your portal >> you call Certmonger on the local system via CLI or D-BUS interface >> and it gets a cert for you. >> But I need to understand the workflow better. If you generate he PKI >> pair on you portal and deliver them to a device it is a perfect >> solution. If you use client side software on the mobile platform to >> send the signing request then it is a different workflow and you need >> to send such request to CA. >> >>> ?Desirable - Export a key store (including cert) as PKCS#12, PEM >>> (for manual deployment of certs on e.g. SSL servers). >>> >> >> When and where? During issuance or ability to later export it from >> the back end store? >> >>> As mentioned earlier we are planning to use a CA for issuing and >>> delivering certs to mobile devices via SCEP. >>> >> >> I am sorry I am not familiar with the details of the workflow in this >> case. >> Can you describe the chain of communication between mobile device, >> your portal and CA and what protocols used where? > iOS devices uses SCEP to enroll for certificates. The basic flow is > that you have a "Profile Server", which is responsible for delivering > a XML profile onto the authenticated iOS device. This XML profile > contains details on how the iOS device should contact the CA via SCEP. > When the profile is installed, the SCEP request is made and the > returned certificate is installed. There is a good visual workflow of > this process in this document: > > https://developer.apple.com/library/ios/documentation/networkinginternet/conceptual/iphoneotaconfiguration/OTASecurity/OTASecurity.html#//apple_ref/doc/uid/TP40009505-CH3-SW1 > > This is very helpful. So it seems that IPA CA might be used for this as is. The certs would just not be associeted with any specific entry and leave in the CA storage. Do I get it right? The trick might be to add additional profile to IPA CA after IPA installation and use that profile instead of the default one in SCEP requests. Since with Dogtag 10 you have REST API and CLI to add and manage those profiles and the data is sort of orthogonal to IPA data I do not see a reason why portal can't integrate those and use them directly. > -NGK >> >>> So far we managed to issue certs for iphones via SCEP in ejbCA and >>> Dogtag (pki-ca 9.0.3-30 package). >>> >>> Dogtag wins provided we can carry on using standalone CA services in >>> the future for free as a part of RHEL IPA? >>> >> >> Yes this is a clear winner keeping in mind that we had some distant >> plans about the use case you are describing. Unfortunately we were >> not able to get a good understanding of the details of the use case >> in the past thus so many questions. Sorry. >> >> >> Thanks >> Dmitri >> >>> Thanks, >>> >>> Oleg >>> >>> *From:*Dmitri Pal [mailto:dpal at redhat.com] >>> *Sent:* 04 October 2013 16:54 >>> *To:* Oleg Antonenko >>> *Cc:* Nathan Kinder (nkinder at redhat.com); Ciaran Bradley; >>> pki-users at redhat.com >>> *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? >>> >>> On 10/04/2013 11:48 AM, Oleg Antonenko wrote: >>> >>> Hi Dmitri, Nathan, >>> >>> Thank you for speedy responses. >>> >>> Could you please confirm my understanding? >>> >>> RHCS is going to be shipped as a part of RHEL7.x in the foreseeable >>> future; >>> >>> >>> It is not "a part" it is a stand alone product and not free. >>> >>> >>> IPA is a free part of RHEL 6.x and will remain as such in the >>> foreseeable future; >>> >>> >>> Correct and same is true for RHEL7.x >>> >>> >>> RHEL 6.x does not ship RHCS, but includes only pki-ca packages in >>> order to support IPA. >>> >>> >>> Correct >>> >>> >>> Could you also clarify your point here ? >>> >>> /The CA portion in RHEL is not supported by Red Hat for standalone >>> use /*/without an entitlement for the rest of RHCS/*/, which isn't >>> available on RHEL 6/ >>> >>> >>> RHCS is a layered product and can be acquired separately. >>> We do not ship a version of RHCS on top of RHEL6. It is a big >>> product and takes a lot of time to deliver. >>> We decided to skip a major RHEL version. >>> >>> >>> Does it mean RHCS is not free? >>> >>> >>> Correct. >>> >>> Regarding this - >>> >>> /We would be actually very interested if we can support this use >>> case with core IPA. >>> Would you be interested in a conversation about this? >>> >>> >>> / >>> >>> Yes, we?d love to. >>> >>> >>> Ok let us have one. >>> I am sorry, I have not been following the whole thread, just this >>> mail caught my eye so what kind of functionality we are looking for? >>> Can you formulate a "wish list" for your use case assuming the CA is >>> a part of IPA? >>> >>> >>> >>> Many thanks, >>> >>> Oleg >>> >>> *From:*pki-users-bounces at redhat.com >>> >>> [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal >>> *Sent:* 04 October 2013 16:21 >>> *To:* pki-users at redhat.com >>> *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? >>> >>> On 10/04/2013 11:08 AM, Oleg Antonenko wrote: >>> >>> Hi Nathan, >>> >>> Could you please shed some light on the future plans for the pki-ca >>> portion of RHEL? >>> >>> Will it be included in the standard RHEL distribution in the future? >>> >>> >>> Dogtag 10+ will become a RHSC product on top of RHEL7.x >>> >>> Some of its portions will be gradually included into IPA that comes >>> for free with RHEL. >>> IMO full blown IPA is not that "full blown" in this case. >>> >>> We would be actually very interested if we can support this use case >>> with core IPA. >>> Would you be interested in a conversation about this? >>> >>> Thanks >>> Dmitri >>> >>> >>> >>> I?m asking because we?re planning to use the CA bit only for issuing >>> certificates to mobile devices via SCEP. We do not require any other >>> services or the full blown IPA? >>> >>> With thanks, >>> >>> Oleg >>> >>> *From:*pki-users-bounces at redhat.com >>> >>> [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Nathan Kinder >>> *Sent:* 27 September 2013 20:03 >>> *To:* pki-users at redhat.com >>> *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? >>> >>> On 09/26/2013 10:25 PM, ? ? wrote: >>> >>> Hi all, >>> >>> I'm a beginner of the dogtag certificate system, >>> dogtag?RHCS?is a wonderful project, but I'm confused about >>> RHCS, could you give any help? >>> >>> The latest version of RHCS is 8.1, which is based on dogtag 8.1, >>> it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included >>> without the other 5 subsystems, could you show me the >>> consideration why RHCS do not support RHEL6? >>> Is RHEL6 not secure enough or some other reasons? >>> >>> It was simply not a targeted platform (nor are there plans to >>> release it there). The pki-ca portion is included for use by IdM >>> (based on the FreeIPA project). >>> >>> Thanks, >>> -NGK >>> >>> >>> >>> >>> Regards. >>> An Yang >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager for IdM portfolio >>> Red Hat Inc. >>> >>> >>> ------------------------------- >>> Looking to carve out IT costs? >>> www.redhat.com/carveoutcosts/ >>> >>> >>> >>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager for IdM portfolio >>> Red Hat Inc. >>> >>> >>> ------------------------------- >>> Looking to carve out IT costs? >>> www.redhat.com/carveoutcosts/ >>> >>> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Fri Oct 4 19:52:39 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 04 Oct 2013 12:52:39 -0700 Subject: [Pki-users] will the new version of RHCS support RHEL6? In-Reply-To: <524F0AFC.9020700@redhat.com> References: <5245D666.8030508@redhat.com> <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> <524EDCDC.9080802@redhat.com> <34A5A0661B86944184C25952A4F16990869204E7@Exchange-AMS.adaptivemobile.com> <524EE4B2.1010901@redhat.com> <34A5A0661B86944184C25952A4F1699086920502@Exchange-AMS.adaptivemobile.com> <524EFE64.3090803@redhat.com> <524F03C3.4080209@redhat.com> <524F0AFC.9020700@redhat.com> Message-ID: <524F1C87.2010708@redhat.com> On 10/04/2013 11:37 AM, Dmitri Pal wrote: > On 10/04/2013 02:06 PM, Nathan Kinder wrote: >> On 10/04/2013 10:44 AM, Dmitri Pal wrote: >>> On 10/04/2013 12:12 PM, Oleg Antonenko wrote: >>>> >>>> That?s all clear now, thank you Dmitri! >>>> >>>> Regarding our wish list J >>>> >>>> Basically we just have evaluated ejbCA, so we want something >>>> similar but without EJB and heavy weight app server? i.e. - >>>> >>>> ?UI for managing certs >>>> >>> >>> Can you define workflows and actors? >>> Who does what when to the certs? >>> Are certs associated to users or to devices? >>> Do you track devices in the CA or somewhere else? >>> Are users enterprise users (belong to one company) or internet users >>> (any user from the street)? >>> >>>> ?Support SCEP & OCSP >>>> >>> >>> Dogtag supports both. First as a protocol the second one is the >>> component that can be installed and turned on. >>> For SCEP do you actually need a SCEP client ? What do you use a SEP >>> client? >>> Are there any specific features of the SCEP protocol that are >>> required that are currently natively not supported by the Dogtag CA? >>> >>>> ?API for issuing and revoking certs (cert-based request auth is >>>> preferrable) -- as we want to integrate out product for revoking certs >>>> >>> >>> The product can be given a keytab and authenticate kerberos to the >>> IPA. It is very simple and would be easier to accomplish. >>> API for managing serts for hosts and services already available in >>> IPA so the question is what the certs are associated with is very >>> important. >>> Also certmonger can be used for fetching certs and storing them in >>> the files or DBs you need. >>> Are you aware of certmonger? >>> It can be effectively a whole alternative solution. From your portal >>> you call Certmonger on the local system via CLI or D-BUS interface >>> and it gets a cert for you. >>> But I need to understand the workflow better. If you generate he PKI >>> pair on you portal and deliver them to a device it is a perfect >>> solution. If you use client side software on the mobile platform to >>> send the signing request then it is a different workflow and you >>> need to send such request to CA. >>> >>>> ?Desirable - Export a key store (including cert) as PKCS#12, PEM >>>> (for manual deployment of certs on e.g. SSL servers). >>>> >>> >>> When and where? During issuance or ability to later export it from >>> the back end store? >>> >>>> As mentioned earlier we are planning to use a CA for issuing and >>>> delivering certs to mobile devices via SCEP. >>>> >>> >>> I am sorry I am not familiar with the details of the workflow in >>> this case. >>> Can you describe the chain of communication between mobile device, >>> your portal and CA and what protocols used where? >> iOS devices uses SCEP to enroll for certificates. The basic flow is >> that you have a "Profile Server", which is responsible for delivering >> a XML profile onto the authenticated iOS device. This XML profile >> contains details on how the iOS device should contact the CA via >> SCEP. When the profile is installed, the SCEP request is made and the >> returned certificate is installed. There is a good visual workflow of >> this process in this document: >> >> https://developer.apple.com/library/ios/documentation/networkinginternet/conceptual/iphoneotaconfiguration/OTASecurity/OTASecurity.html#//apple_ref/doc/uid/TP40009505-CH3-SW1 >> >> > > This is very helpful. > So it seems that IPA CA might be used for this as is. The certs would > just not be associeted with any specific entry and leave in the CA > storage. > Do I get it right? I think so. > > The trick might be to add additional profile to IPA CA after IPA > installation and use that profile instead of the default one in SCEP > requests. Yes, getting the profile set up would be then main thing to tackle. > > Since with Dogtag 10 you have REST API and CLI to add and manage those > profiles and the data is sort of orthogonal to IPA data I do not see a > reason why portal can't integrate those and use them directly. To clarify, profile management REST interfaces are in Dogag 10.1 (not 10.0). Regardless, profiles can be configured without the REST interfaces and be used directly with IPA being none the wiser. > > >> -NGK >>> >>>> So far we managed to issue certs for iphones via SCEP in ejbCA and >>>> Dogtag (pki-ca 9.0.3-30 package). >>>> >>>> Dogtag wins provided we can carry on using standalone CA services >>>> in the future for free as a part of RHEL IPA? >>>> >>> >>> Yes this is a clear winner keeping in mind that we had some distant >>> plans about the use case you are describing. Unfortunately we were >>> not able to get a good understanding of the details of the use case >>> in the past thus so many questions. Sorry. >>> >>> >>> Thanks >>> Dmitri >>> >>>> Thanks, >>>> >>>> Oleg >>>> >>>> *From:*Dmitri Pal [mailto:dpal at redhat.com] >>>> *Sent:* 04 October 2013 16:54 >>>> *To:* Oleg Antonenko >>>> *Cc:* Nathan Kinder (nkinder at redhat.com); Ciaran Bradley; >>>> pki-users at redhat.com >>>> *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? >>>> >>>> On 10/04/2013 11:48 AM, Oleg Antonenko wrote: >>>> >>>> Hi Dmitri, Nathan, >>>> >>>> Thank you for speedy responses. >>>> >>>> Could you please confirm my understanding? >>>> >>>> RHCS is going to be shipped as a part of RHEL7.x in the foreseeable >>>> future; >>>> >>>> >>>> It is not "a part" it is a stand alone product and not free. >>>> >>>> >>>> IPA is a free part of RHEL 6.x and will remain as such in the >>>> foreseeable future; >>>> >>>> >>>> Correct and same is true for RHEL7.x >>>> >>>> >>>> RHEL 6.x does not ship RHCS, but includes only pki-ca packages in >>>> order to support IPA. >>>> >>>> >>>> Correct >>>> >>>> >>>> Could you also clarify your point here ? >>>> >>>> /The CA portion in RHEL is not supported by Red Hat for standalone >>>> use /*/without an entitlement for the rest of RHCS/*/, which isn't >>>> available on RHEL 6/ >>>> >>>> >>>> RHCS is a layered product and can be acquired separately. >>>> We do not ship a version of RHCS on top of RHEL6. It is a big >>>> product and takes a lot of time to deliver. >>>> We decided to skip a major RHEL version. >>>> >>>> >>>> Does it mean RHCS is not free? >>>> >>>> >>>> Correct. >>>> >>>> Regarding this - >>>> >>>> /We would be actually very interested if we can support this use >>>> case with core IPA. >>>> Would you be interested in a conversation about this? >>>> >>>> >>>> / >>>> >>>> Yes, we?d love to. >>>> >>>> >>>> Ok let us have one. >>>> I am sorry, I have not been following the whole thread, just this >>>> mail caught my eye so what kind of functionality we are looking for? >>>> Can you formulate a "wish list" for your use case assuming the CA >>>> is a part of IPA? >>>> >>>> >>>> >>>> Many thanks, >>>> >>>> Oleg >>>> >>>> *From:*pki-users-bounces at redhat.com >>>> >>>> [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal >>>> *Sent:* 04 October 2013 16:21 >>>> *To:* pki-users at redhat.com >>>> *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? >>>> >>>> On 10/04/2013 11:08 AM, Oleg Antonenko wrote: >>>> >>>> Hi Nathan, >>>> >>>> Could you please shed some light on the future plans for the pki-ca >>>> portion of RHEL? >>>> >>>> Will it be included in the standard RHEL distribution in the future? >>>> >>>> >>>> Dogtag 10+ will become a RHSC product on top of RHEL7.x >>>> >>>> Some of its portions will be gradually included into IPA that comes >>>> for free with RHEL. >>>> IMO full blown IPA is not that "full blown" in this case. >>>> >>>> We would be actually very interested if we can support this use >>>> case with core IPA. >>>> Would you be interested in a conversation about this? >>>> >>>> Thanks >>>> Dmitri >>>> >>>> >>>> >>>> I?m asking because we?re planning to use the CA bit only for >>>> issuing certificates to mobile devices via SCEP. We do not require >>>> any other services or the full blown IPA? >>>> >>>> With thanks, >>>> >>>> Oleg >>>> >>>> *From:*pki-users-bounces at redhat.com >>>> >>>> [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Nathan Kinder >>>> *Sent:* 27 September 2013 20:03 >>>> *To:* pki-users at redhat.com >>>> *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? >>>> >>>> On 09/26/2013 10:25 PM, ? ? wrote: >>>> >>>> Hi all, >>>> >>>> I'm a beginner of the dogtag certificate system, >>>> dogtag?RHCS?is a wonderful project, but I'm confused about >>>> RHCS, could you give any help? >>>> >>>> The latest version of RHCS is 8.1, which is based on dogtag >>>> 8.1, it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was >>>> included without the other 5 subsystems, could you show me the >>>> consideration why RHCS do not support RHEL6? >>>> Is RHEL6 not secure enough or some other reasons? >>>> >>>> It was simply not a targeted platform (nor are there plans to >>>> release it there). The pki-ca portion is included for use by IdM >>>> (based on the FreeIPA project). >>>> >>>> Thanks, >>>> -NGK >>>> >>>> >>>> >>>> >>>> Regards. >>>> An Yang >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager for IdM portfolio >>>> Red Hat Inc. >>>> >>>> >>>> ------------------------------- >>>> Looking to carve out IT costs? >>>> www.redhat.com/carveoutcosts/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager for IdM portfolio >>>> Red Hat Inc. >>>> >>>> >>>> ------------------------------- >>>> Looking to carve out IT costs? >>>> www.redhat.com/carveoutcosts/ >>>> >>>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager for IdM portfolio >>> Red Hat Inc. >>> >>> >>> ------------------------------- >>> Looking to carve out IT costs? >>> www.redhat.com/carveoutcosts/ >>> >>> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Oleg.Antonenko at adaptivemobile.com Mon Oct 7 09:19:10 2013 From: Oleg.Antonenko at adaptivemobile.com (Oleg Antonenko) Date: Mon, 7 Oct 2013 09:19:10 +0000 Subject: [Pki-users] will the new version of RHCS support RHEL6? In-Reply-To: <524F1C87.2010708@redhat.com> References: <5245D666.8030508@redhat.com> <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> <524EDCDC.9080802@redhat.com> <34A5A0661B86944184C25952A4F16990869204E7@Exchange-AMS.adaptivemobile.com> <524EE4B2.1010901@redhat.com> <34A5A0661B86944184C25952A4F1699086920502@Exchange-AMS.adaptivemobile.com> <524EFE64.3090803@redhat.com> <524F03C3.4080209@redhat.com> <524F0AFC.9020700@redhat.com> <524F1C87.2010708@redhat.com> Message-ID: <34A5A0661B86944184C25952A4F16990869205EF@Exchange-AMS.adaptivemobile.com> Hi Nathan, Dmitri, Thanks for the info and your comments. Please see my answers inline in red? From: Nathan Kinder [mailto:nkinder at redhat.com] Sent: 04 October 2013 20:53 To: dpal at redhat.com Cc: Oleg Antonenko; Ciaran Bradley; pki-users at redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/04/2013 11:37 AM, Dmitri Pal wrote: On 10/04/2013 02:06 PM, Nathan Kinder wrote: On 10/04/2013 10:44 AM, Dmitri Pal wrote: On 10/04/2013 12:12 PM, Oleg Antonenko wrote: That?s all clear now, thank you Dmitri! Regarding our wish list :) Basically we just have evaluated ejbCA, so we want something similar but without EJB and heavy weight app server? i.e. - UI for managing certs Can you define workflows and actors? [OA] Workflow for iOS devices is well defined in the Apple?s guide referenced below. We will be building similar for Android - but simpler without a Profile Server. We use an MDM system for distributing SCEP profile/configuration to devices? Who does what when to the certs? [OA] Device itself plays a role of a SCEP client. After obtaining a cert devices would you use for setting up a VPN channel. Normally we are not planning actively manage certs for devices, except revocation. But for SSL servers we would have to issue certs manually, and then export full keysotre for manual deployment. Are certs associated to users or to devices? [OA] To devices, so the CN will contain a device ID. At the same time subjectAltName will be set to user?s email. So in theory it would be good to manage users but that is for the future? Do you track devices in the CA or somewhere else? [OA] No, we will track them in our application, which will be integrated with MDM for device enrolment and configuration (e.g. installing our VPN Client App & setting up SCEP Profile). So we will need the CA API only for revoking certs. Are users enterprise users (belong to one company) or internet users (any user from the street)? [OA] Enterprise Support SCEP & OCSP Dogtag supports both. First as a protocol the second one is the component that can be installed and turned on. [OA] Those are reasons for selecting it For SCEP do you actually need a SCEP client ? What do you use a SEP client? [OA] For iOS I presume there is an embedded client? For Android we?re developing our own. Are there any specific features of the SCEP protocol that are required that are currently natively not supported by the Dogtag CA? [OA] There is one area I still don?t have full understanding of. In the SCEP specs they say that a request for a cert is a PKCS#7 structure signed by either - * A cert issued earlier by the requested CA (re-issuance) * Self-signed cert * A 3rd party cert signed by a trusted CA (e.g. a generic transport cert) The P7 structure contains a P10 request encrypted with the requested CA pub key. When testing issuing certs for iOS devices in dogtag our developers had an impression that the P10 is not encrypted, and the P7 is not signed. I?m frankly not convinced by their words. Could you confirm please that the SCEP cert request is processed in dogtag as above? API for issuing and revoking certs (cert-based request auth is preferrable) - as we want to integrate out product for revoking certs The product can be given a keytab and authenticate kerberos to the IPA. It is very simple and would be easier to accomplish. API for managing serts for hosts and services already available in IPA so the question is what the certs are associated with is very important. Also certmonger can be used for fetching certs and storing them in the files or DBs you need. Are you aware of certmonger? [OA] No, did not hear before. As I understand it has a command line / d-bus interfaces? We need something like a WS or REST. It can be effectively a whole alternative solution. From your portal you call Certmonger on the local system via CLI or D-BUS interface and it gets a cert for you. But I need to understand the workflow better. If you generate he PKI pair on you portal and deliver them to a device it is a perfect solution. If you use client side software on the mobile platform to send the signing request then it is a different workflow and you need to send such request to CA. [OA] Yes, the latter? Desirable - Export a key store (including cert) as PKCS#12, PEM (for manual deployment of certs on e.g. SSL servers). When and where? During issuance or ability to later export it from the back end store? [OA] For SSL serves terminating VPN connection from mobile devices. So we would create them before and parallel to issuing to devices? I think it?s going to be like an admin would login into the UI, enter machine details for the cert & key store. In response the CA would generate a keypair and issue a cert. Then we would need to export the keystore either as p12 or PEM file? As mentioned earlier we are planning to use a CA for issuing and delivering certs to mobile devices via SCEP. I am sorry I am not familiar with the details of the workflow in this case. Can you describe the chain of communication between mobile device, your portal and CA and what protocols used where? iOS devices uses SCEP to enroll for certificates. The basic flow is that you have a "Profile Server", which is responsible for delivering a XML profile onto the authenticated iOS device. This XML profile contains details on how the iOS device should contact the CA via SCEP. When the profile is installed, the SCEP request is made and the returned certificate is installed. There is a good visual workflow of this process in this document: https://developer.apple.com/library/ios/documentation/networkinginternet/conceptual/iphoneotaconfiguration/OTASecurity/OTASecurity.html#//apple_ref/doc/uid/TP40009505-CH3-SW1 This is very helpful. So it seems that IPA CA might be used for this as is. The certs would just not be associeted with any specific entry and leave in the CA storage. Do I get it right? I think so. [OA] Yes, correct. Btw, what storage the CA is using? Ldap? The trick might be to add additional profile to IPA CA after IPA installation and use that profile instead of the default one in SCEP requests. Yes, getting the profile set up would be then main thing to tackle. [OA] Could you give me a bit more insight what is advantage/why to use an additional SCEP profile? Since with Dogtag 10 you have REST API and CLI to add and manage those profiles and the data is sort of orthogonal to IPA data I do not see a reason why portal can't integrate those and use them directly. To clarify, profile management REST interfaces are in Dogag 10.1 (not 10.0). Regardless, profiles can be configured without the REST interfaces and be used directly with IPA being none the wiser. [OA] We would configure the CA manually. API is needed for cert revocation only. Does dogtag 9 supports REST for revocation? -NGK So far we managed to issue certs for iphones via SCEP in ejbCA and Dogtag (pki-ca 9.0.3-30 package). Dogtag wins provided we can carry on using standalone CA services in the future for free as a part of RHEL IPA? Yes this is a clear winner keeping in mind that we had some distant plans about the use case you are describing. Unfortunately we were not able to get a good understanding of the details of the use case in the past thus so many questions. Sorry. [OA] That?s cool, it seems you?ve got it right? Thanks Dmitri Thanks, Oleg From: Dmitri Pal [mailto:dpal at redhat.com] Sent: 04 October 2013 16:54 To: Oleg Antonenko Cc: Nathan Kinder (nkinder at redhat.com); Ciaran Bradley; pki-users at redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/04/2013 11:48 AM, Oleg Antonenko wrote: Hi Dmitri, Nathan, Thank you for speedy responses. Could you please confirm my understanding? RHCS is going to be shipped as a part of RHEL7.x in the foreseeable future; It is not "a part" it is a stand alone product and not free. IPA is a free part of RHEL 6.x and will remain as such in the foreseeable future; Correct and same is true for RHEL7.x RHEL 6.x does not ship RHCS, but includes only pki-ca packages in order to support IPA. Correct Could you also clarify your point here ? The CA portion in RHEL is not supported by Red Hat for standalone use without an entitlement for the rest of RHCS, which isn't available on RHEL 6 RHCS is a layered product and can be acquired separately. We do not ship a version of RHCS on top of RHEL6. It is a big product and takes a lot of time to deliver. We decided to skip a major RHEL version. Does it mean RHCS is not free? Correct. Regarding this - We would be actually very interested if we can support this use case with core IPA. Would you be interested in a conversation about this? Yes, we?d love to. Ok let us have one. I am sorry, I have not been following the whole thread, just this mail caught my eye so what kind of functionality we are looking for? Can you formulate a "wish list" for your use case assuming the CA is a part of IPA? Many thanks, Oleg From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: 04 October 2013 16:21 To: pki-users at redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/04/2013 11:08 AM, Oleg Antonenko wrote: Hi Nathan, Could you please shed some light on the future plans for the pki-ca portion of RHEL? Will it be included in the standard RHEL distribution in the future? Dogtag 10+ will become a RHSC product on top of RHEL7.x Some of its portions will be gradually included into IPA that comes for free with RHEL. IMO full blown IPA is not that "full blown" in this case. We would be actually very interested if we can support this use case with core IPA. Would you be interested in a conversation about this? Thanks Dmitri I?m asking because we?re planning to use the CA bit only for issuing certificates to mobile devices via SCEP. We do not require any other services or the full blown IPA? With thanks, Oleg From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Nathan Kinder Sent: 27 September 2013 20:03 To: pki-users at redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 09/26/2013 10:25 PM, ? ? wrote: Hi all, I'm a beginner of the dogtag certificate system, dogtag?RHCS?is a wonderful project, but I'm confused about RHCS, could you give any help? The latest version of RHCS is 8.1, which is based on dogtag 8.1, it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included without the other 5 subsystems, could you show me the consideration why RHCS do not support RHEL6? Is RHEL6 not secure enough or some other reasons? It was simply not a targeted platform (nor are there plans to release it there). The pki-ca portion is included for use by IdM (based on the FreeIPA project). Thanks, -NGK Regards. An Yang _______________________________________________ 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 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Oct 7 13:30:46 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 07 Oct 2013 09:30:46 -0400 Subject: [Pki-users] will the new version of RHCS support RHEL6? In-Reply-To: <34A5A0661B86944184C25952A4F16990869205EF@Exchange-AMS.adaptivemobile.com> References: <5245D666.8030508@redhat.com> <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> <524EDCDC.9080802@redhat.com> <34A5A0661B86944184C25952A4F16990869204E7@Exchange-AMS.adaptivemobile.com> <524EE4B2.1010901@redhat.com> <34A5A0661B86944184C25952A4F1699086920502@Exchange-AMS.adaptivemobile.com> <524EFE64.3090803@redhat.com> <524F03C3.4080209@redhat.com> <524F0AFC.9020700@redhat.com> <524F1C87.2010708@redhat.com> <34A5A0661B86944184C25952A4F16990869205EF@Exchange-AMS.adaptivemobile.com> Message-ID: <5252B786.2080201@redhat.com> On 10/07/2013 05:19 AM, Oleg Antonenko wrote: > > Hi Nathan, Dmitri, > > Thanks for the info and your comments. Please see my answers inline in > red? > > *From:*Nathan Kinder [mailto:nkinder at redhat.com] > *Sent:* 04 October 2013 20:53 > *To:* dpal at redhat.com > *Cc:* Oleg Antonenko; Ciaran Bradley; pki-users at redhat.com > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > On 10/04/2013 11:37 AM, Dmitri Pal wrote: > > On 10/04/2013 02:06 PM, Nathan Kinder wrote: > > On 10/04/2013 10:44 AM, Dmitri Pal wrote: > > On 10/04/2013 12:12 PM, Oleg Antonenko wrote: > > That?s all clear now, thank you Dmitri! > > Regarding our wish list J > > Basically we just have evaluated ejbCA, so we want something > similar but without EJB and heavy weight app server? i.e. - > > UI for managing certs > > > Can you define workflows and actors? > > [OA] Workflow for iOS devices is well defined in the Apple?s > guide referenced below. We will be building similar for > Android -- but simpler without a Profile Server. We use an MDM > system for distributing SCEP profile/configuration to devices? > > > Who does what when to the certs? > > [OA] Device itself plays a role of a SCEP client. After > obtaining a cert devices would you use for setting up a VPN > channel. Normally we are not planning actively manage certs > for devices, except revocation. But for SSL servers we would > have to issue certs manually, and then export full keysotre > for manual deployment. > > > Are certs associated to users or to devices? > > [OA] To devices, so the CN will contain a device ID. At the > same time subjectAltName will be set to user?s email. So in > theory it would be good to manage users but that is for the > future? > > > Do you track devices in the CA or somewhere else? > > [OA] No, we will track them in our application, which will be > integrated with MDM for device enrolment and configuration > (e.g. installing our VPN Client App & setting up SCEP > Profile). So we will need the CA API only for revoking certs. > Are users enterprise users (belong to one company) or internet > users (any user from the street)? > > [OA] Enterprise > > > > > Support SCEP & OCSP > > > Dogtag supports both. First as a protocol the second one is > the component that can be installed and turned on. > > [OA] Those are reasons for selecting it > > For SCEP do you actually need a SCEP client ? What do you use > a SEP client? > > [OA] For iOS I presume there is an embedded client? For > Android we?re developing our own. > > Are there any specific features of the SCEP protocol that are > required that are currently natively not supported by the > Dogtag CA? > [OA] There is one area I still don?t have full understanding of. > > In the SCEP specs they say that a request for a cert is a > PKCS#7 structure signed by either -- > > ?A cert issued earlier by the requested CA (re-issuance) > > ?Self-signed cert > > ?A 3^rd party cert signed by a trusted CA (e.g. a generic > transport cert) > > The P7 structure contains a P10 request encrypted with the > requested CA pub key. > > When testing issuing certs for iOS devices in dogtag our > developers had an impression that the P10 is not encrypted, > and the P7 is not signed. I?m frankly not convinced by their > words. Could you confirm please that the SCEP cert request is > processed in dogtag as above? > > I would leave this to Nathan to confirm. > > API for issuing and revoking certs (cert-based request auth is > preferrable) -- as we want to integrate out product for > revoking certs > > > The product can be given a keytab and authenticate kerberos to > the IPA. It is very simple and would be easier to accomplish. > API for managing serts for hosts and services already > available in IPA so the question is what the certs are > associated with is very important. > Also certmonger can be used for fetching certs and storing > them in the files or DBs you need. > Are you aware of certmonger? > > [OA] No, did not hear before. As I understand it has a command > line / d-bus interfaces? We need something like a WS or REST. > The point is that you can create a simple WS or REST server around it very easily. > > It can be effectively a whole alternative solution. From your > portal you call Certmonger on the local system via CLI or > D-BUS interface and it gets a cert for you. > But I need to understand the workflow better. If you generate > he PKI pair on you portal and deliver them to a device it is a > perfect solution. If you use client side software on the > mobile platform to send the signing request then it is a > different workflow and you need to send such request to > CA.[OA] Yes, the latter? > I see. > > > Desirable - Export a key store (including cert) as PKCS#12, > PEM (for manual deployment of certs on e.g. SSL servers). > > > When and where? During issuance or ability to later export it > from the back end store? > > [OA] For SSL serves terminating VPN connection from mobile > devices. So we would create them before and parallel to > issuing to devices? I think it?s going to be like an admin > would login into the UI, enter machine details for the cert & > key store. In response the CA would generate a keypair and > issue a cert. Then we would need to export the keystore either > as p12 or PEM file? > You might want to consider using IPA to mange servers and their certs. AFAIR IPA allows you to save certs in a PEM file. Then for the devices you will use Dogtag directly but for servers you will leverage all the advantages of IPA. Seems like a double win. > As mentioned earlier we are planning to use a CA for issuing > and delivering certs to mobile devices via SCEP. > > > I am sorry I am not familiar with the details of the workflow > in this case. > Can you describe the chain of communication between mobile > device, your portal and CA and what protocols used where? > > iOS devices uses SCEP to enroll for certificates. The basic flow > is that you have a "Profile Server", which is responsible for > delivering a XML profile onto the authenticated iOS device. This > XML profile contains details on how the iOS device should contact > the CA via SCEP. When the profile is installed, the SCEP request > is made and the returned certificate is installed. There is a good > visual workflow of this process in this document: > > https://developer.apple.com/library/ios/documentation/networkinginternet/conceptual/iphoneotaconfiguration/OTASecurity/OTASecurity.html#//apple_ref/doc/uid/TP40009505-CH3-SW1 > > > > This is very helpful. > So it seems that IPA CA might be used for this as is. The certs > would just not be associeted with any specific entry and leave in > the CA storage. > Do I get it right? > > I think so.[OA] Yes, correct. Btw, what storage the CA is using? Ldap? > Yes. > > > The trick might be to add additional profile to IPA CA after IPA > installation and use that profile instead of the default one in SCEP > requests. > > Yes, getting the profile set up would be then main thing to tackle. > > [OA] Could you give me a bit more insight what is advantage/why to use > an additional SCEP profile? > Cert profile is a template for issuing certs. Dogtag allows you to have more than a single template. This makes possible to issue certs containing different contents and used for different purposes: VPN, authentication, message signing etc. IPA installs just one profile. I suspect that mobile devices would need to have certs with specific attributes in them. For that you would need to either modify the existing profile or add another one. Latest versions of Dogtag CA have REST API to manage these profiles programmatically but this capability is not integrated into IPA yet. So with existing IPA version you would need to either modify existing profile or add a new one manually. If you start with latest Dogtag and version in Fedora 19 that will be a part of RHEL7 you can probably use REST API directly and add/modify profiles as you need. In future IPA will provide API/CLI/UI that would wrap this REST API and allow you to mange this consistently with the rest of the IPA objects. > > > Since with Dogtag 10 you have REST API and CLI to add and manage those > profiles and the data is sort of orthogonal to IPA data I do not see a > reason why portal can't integrate those and use them directly. > > To clarify, profile management REST interfaces are in Dogag 10.1 (not > 10.0). Regardless, profiles can be configured without the REST > interfaces and be used directly with IPA being none the wiser. > [OA] We would configure the CA manually. API is needed for cert > revocation only. Does dogtag 9 supports REST for revocation? > Dogtag 9 does not support any REST API. > > > > > -NGK > > > > So far we managed to issue certs for iphones via SCEP in ejbCA and > Dogtag (pki-ca 9.0.3-30 package). > > Dogtag wins provided we can carry on using standalone CA services in > the future for free as a part of RHEL IPA? > > > Yes this is a clear winner keeping in mind that we had some distant > plans about the use case you are describing. Unfortunately we were not > able to get a good understanding of the details of the use case in the > past thus so many questions. Sorry. > [OA] That?s cool, it seems you?ve got it right? > We would like to help you as much as possible with what we have now and give you a clear migration path for the solutions we are building. This is why Dogtag 10+ and IPA 3.2+ is probably the best starting point. > > Thanks > Dmitri > > > Thanks, > > Oleg > > *From:*Dmitri Pal [mailto:dpal at redhat.com] > *Sent:* 04 October 2013 16:54 > *To:* Oleg Antonenko > *Cc:* Nathan Kinder (nkinder at redhat.com ); > Ciaran Bradley; pki-users at redhat.com > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > On 10/04/2013 11:48 AM, Oleg Antonenko wrote: > > Hi Dmitri, Nathan, > > Thank you for speedy responses. > > Could you please confirm my understanding? > > RHCS is going to be shipped as a part of RHEL7.x in the foreseeable > future; > > > It is not "a part" it is a stand alone product and not free. > > > > IPA is a free part of RHEL 6.x and will remain as such in the > foreseeable future; > > > Correct and same is true for RHEL7.x > > > > RHEL 6.x does not ship RHCS, but includes only pki-ca packages in > order to support IPA. > > > Correct > > > > Could you also clarify your point here ? > > /The CA portion in RHEL is not supported by Red Hat for standalone use > /*/without an entitlement for the rest of RHCS/*/, which isn't > available on RHEL 6/ > > > RHCS is a layered product and can be acquired separately. > We do not ship a version of RHCS on top of RHEL6. It is a big product > and takes a lot of time to deliver. > We decided to skip a major RHEL version. > > > > Does it mean RHCS is not free? > > > Correct. > > > Regarding this - > > /We would be actually very interested if we can support this use case > with core IPA. > Would you be interested in a conversation about this? > > > > / > > Yes, we?d love to. > > > Ok let us have one. > I am sorry, I have not been following the whole thread, just this mail > caught my eye so what kind of functionality we are looking for? > Can you formulate a "wish list" for your use case assuming the CA is a > part of IPA? > > > > > Many thanks, > > Oleg > > *From:*pki-users-bounces at redhat.com > > [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* 04 October 2013 16:21 > *To:* pki-users at redhat.com > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > On 10/04/2013 11:08 AM, Oleg Antonenko wrote: > > Hi Nathan, > > Could you please shed some light on the future plans for the pki-ca > portion of RHEL? > > Will it be included in the standard RHEL distribution in the future? > > > Dogtag 10+ will become a RHSC product on top of RHEL7.x > > Some of its portions will be gradually included into IPA that comes > for free with RHEL. > IMO full blown IPA is not that "full blown" in this case. > > We would be actually very interested if we can support this use case > with core IPA. > Would you be interested in a conversation about this? > > Thanks > Dmitri > > > > > I?m asking because we?re planning to use the CA bit only for issuing > certificates to mobile devices via SCEP. We do not require any other > services or the full blown IPA? > > With thanks, > > Oleg > > *From:*pki-users-bounces at redhat.com > > [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Nathan Kinder > *Sent:* 27 September 2013 20:03 > *To:* pki-users at redhat.com > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > On 09/26/2013 10:25 PM, ? ? wrote: > > Hi all, > > I'm a beginner of the dogtag certificate system, dogtag?RHCS?is > a wonderful project, but I'm confused about RHCS, could you give > any help? > > The latest version of RHCS is 8.1, which is based on dogtag 8.1, > it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included > without the other 5 subsystems, could you show me the > consideration why RHCS do not support RHEL6? > Is RHEL6 not secure enough or some other reasons? > > It was simply not a targeted platform (nor are there plans to release > it there). The pki-ca portion is included for use by IdM (based on the > FreeIPA project). > > Thanks, > -NGK > > > > > > Regards. > An Yang > > > > > > > _______________________________________________ > 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 > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Oleg.Antonenko at adaptivemobile.com Mon Oct 7 13:58:47 2013 From: Oleg.Antonenko at adaptivemobile.com (Oleg Antonenko) Date: Mon, 7 Oct 2013 13:58:47 +0000 Subject: [Pki-users] will the new version of RHCS support RHEL6? In-Reply-To: <5252B786.2080201@redhat.com> References: <5245D666.8030508@redhat.com> <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> <524EDCDC.9080802@redhat.com> <34A5A0661B86944184C25952A4F16990869204E7@Exchange-AMS.adaptivemobile.com> <524EE4B2.1010901@redhat.com> <34A5A0661B86944184C25952A4F1699086920502@Exchange-AMS.adaptivemobile.com> <524EFE64.3090803@redhat.com> <524F03C3.4080209@redhat.com> <524F0AFC.9020700@redhat.com> <524F1C87.2010708@redhat.com> <34A5A0661B86944184C25952A4F16990869205EF@Exchange-AMS.adaptivemobile.com> <5252B786.2080201@redhat.com> Message-ID: <34A5A0661B86944184C25952A4F1699086920680@Exchange-AMS.adaptivemobile.com> Thanks Dmitri. It would be nice to get a confirmation from Nathan regarding p7/p10 signing/encryption when dogtag processes SCEP requests. Here I just wanted to clarify some pointers on Cert Profiles. The trick might be to add additional profile to IPA CA after IPA installation and use that profile instead of the default one in SCEP requests. Yes, getting the profile set up would be then main thing to tackle. [OA] Could you give me a bit more insight what is advantage/why to use an additional SCEP profile? Cert profile is a template for issuing certs. Dogtag allows you to have more than a single template. This makes possible to issue certs containing different contents and used for different purposes: VPN, authentication, message signing etc. IPA installs just one profile. I suspect that mobile devices would need to have certs with specific attributes in them. For that you would need to either modify the existing profile or add another one. Latest versions of Dogtag CA have REST API to manage these profiles programmatically but this capability is not integrated into IPA yet. So with existing IPA version you would need to either modify existing profile or add a new one manually. [OA-2] This is a desirable option. We did not explore the current dogtag 9.0 UI much, so I?m sorry if this is trivial. Does this UI provide a function for creating/setting up new Cert Profiles? If you start with latest Dogtag and version in Fedora 19 that will be a part of RHEL7 you can probably use REST API directly and add/modify profiles as you need. In future IPA will provide API/CLI/UI that would wrap this REST API and allow you to mange this consistently with the rest of the IPA objects. From: Dmitri Pal [mailto:dpal at redhat.com] Sent: 07 October 2013 14:31 To: Oleg Antonenko Cc: Nathan Kinder; Ciaran Bradley; pki-users at redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/07/2013 05:19 AM, Oleg Antonenko wrote: Hi Nathan, Dmitri, Thanks for the info and your comments. Please see my answers inline in red? From: Nathan Kinder [mailto:nkinder at redhat.com] Sent: 04 October 2013 20:53 To: dpal at redhat.com Cc: Oleg Antonenko; Ciaran Bradley; pki-users at redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/04/2013 11:37 AM, Dmitri Pal wrote: On 10/04/2013 02:06 PM, Nathan Kinder wrote: On 10/04/2013 10:44 AM, Dmitri Pal wrote: On 10/04/2013 12:12 PM, Oleg Antonenko wrote: That?s all clear now, thank you Dmitri! Regarding our wish list :) Basically we just have evaluated ejbCA, so we want something similar but without EJB and heavy weight app server? i.e. - UI for managing certs Can you define workflows and actors? [OA] Workflow for iOS devices is well defined in the Apple?s guide referenced below. We will be building similar for Android - but simpler without a Profile Server. We use an MDM system for distributing SCEP profile/configuration to devices? Who does what when to the certs? [OA] Device itself plays a role of a SCEP client. After obtaining a cert devices would you use for setting up a VPN channel. Normally we are not planning actively manage certs for devices, except revocation. But for SSL servers we would have to issue certs manually, and then export full keysotre for manual deployment. Are certs associated to users or to devices? [OA] To devices, so the CN will contain a device ID. At the same time subjectAltName will be set to user?s email. So in theory it would be good to manage users but that is for the future? Do you track devices in the CA or somewhere else? [OA] No, we will track them in our application, which will be integrated with MDM for device enrolment and configuration (e.g. installing our VPN Client App & setting up SCEP Profile). So we will need the CA API only for revoking certs. Are users enterprise users (belong to one company) or internet users (any user from the street)? [OA] Enterprise Support SCEP & OCSP Dogtag supports both. First as a protocol the second one is the component that can be installed and turned on. [OA] Those are reasons for selecting it For SCEP do you actually need a SCEP client ? What do you use a SEP client? [OA] For iOS I presume there is an embedded client? For Android we?re developing our own. Are there any specific features of the SCEP protocol that are required that are currently natively not supported by the Dogtag CA? [OA] There is one area I still don?t have full understanding of. In the SCEP specs they say that a request for a cert is a PKCS#7 structure signed by either - * A cert issued earlier by the requested CA (re-issuance) * Self-signed cert * A 3rd party cert signed by a trusted CA (e.g. a generic transport cert) The P7 structure contains a P10 request encrypted with the requested CA pub key. When testing issuing certs for iOS devices in dogtag our developers had an impression that the P10 is not encrypted, and the P7 is not signed. I?m frankly not convinced by their words. Could you confirm please that the SCEP cert request is processed in dogtag as above? I would leave this to Nathan to confirm. API for issuing and revoking certs (cert-based request auth is preferrable) - as we want to integrate out product for revoking certs The product can be given a keytab and authenticate kerberos to the IPA. It is very simple and would be easier to accomplish. API for managing serts for hosts and services already available in IPA so the question is what the certs are associated with is very important. Also certmonger can be used for fetching certs and storing them in the files or DBs you need. Are you aware of certmonger? [OA] No, did not hear before. As I understand it has a command line / d-bus interfaces? We need something like a WS or REST. The point is that you can create a simple WS or REST server around it very easily. It can be effectively a whole alternative solution. From your portal you call Certmonger on the local system via CLI or D-BUS interface and it gets a cert for you. But I need to understand the workflow better. If you generate he PKI pair on you portal and deliver them to a device it is a perfect solution. If you use client side software on the mobile platform to send the signing request then it is a different workflow and you need to send such request to CA.[OA] Yes, the latter? I see. Desirable - Export a key store (including cert) as PKCS#12, PEM (for manual deployment of certs on e.g. SSL servers). When and where? During issuance or ability to later export it from the back end store? [OA] For SSL serves terminating VPN connection from mobile devices. So we would create them before and parallel to issuing to devices? I think it?s going to be like an admin would login into the UI, enter machine details for the cert & key store. In response the CA would generate a keypair and issue a cert. Then we would need to export the keystore either as p12 or PEM file? You might want to consider using IPA to mange servers and their certs. AFAIR IPA allows you to save certs in a PEM file. Then for the devices you will use Dogtag directly but for servers you will leverage all the advantages of IPA. Seems like a double win. As mentioned earlier we are planning to use a CA for issuing and delivering certs to mobile devices via SCEP. I am sorry I am not familiar with the details of the workflow in this case. Can you describe the chain of communication between mobile device, your portal and CA and what protocols used where? iOS devices uses SCEP to enroll for certificates. The basic flow is that you have a "Profile Server", which is responsible for delivering a XML profile onto the authenticated iOS device. This XML profile contains details on how the iOS device should contact the CA via SCEP. When the profile is installed, the SCEP request is made and the returned certificate is installed. There is a good visual workflow of this process in this document: https://developer.apple.com/library/ios/documentation/networkinginternet/conceptual/iphoneotaconfiguration/OTASecurity/OTASecurity.html#//apple_ref/doc/uid/TP40009505-CH3-SW1 This is very helpful. So it seems that IPA CA might be used for this as is. The certs would just not be associeted with any specific entry and leave in the CA storage. Do I get it right? I think so.[OA] Yes, correct. Btw, what storage the CA is using? Ldap? Yes. The trick might be to add additional profile to IPA CA after IPA installation and use that profile instead of the default one in SCEP requests. Yes, getting the profile set up would be then main thing to tackle. [OA] Could you give me a bit more insight what is advantage/why to use an additional SCEP profile? Cert profile is a template for issuing certs. Dogtag allows you to have more than a single template. This makes possible to issue certs containing different contents and used for different purposes: VPN, authentication, message signing etc. IPA installs just one profile. I suspect that mobile devices would need to have certs with specific attributes in them. For that you would need to either modify the existing profile or add another one. Latest versions of Dogtag CA have REST API to manage these profiles programmatically but this capability is not integrated into IPA yet. So with existing IPA version you would need to either modify existing profile or add a new one manually. If you start with latest Dogtag and version in Fedora 19 that will be a part of RHEL7 you can probably use REST API directly and add/modify profiles as you need. In future IPA will provide API/CLI/UI that would wrap this REST API and allow you to mange this consistently with the rest of the IPA objects. Since with Dogtag 10 you have REST API and CLI to add and manage those profiles and the data is sort of orthogonal to IPA data I do not see a reason why portal can't integrate those and use them directly. To clarify, profile management REST interfaces are in Dogag 10.1 (not 10.0). Regardless, profiles can be configured without the REST interfaces and be used directly with IPA being none the wiser. [OA] We would configure the CA manually. API is needed for cert revocation only. Does dogtag 9 supports REST for revocation? Dogtag 9 does not support any REST API. -NGK So far we managed to issue certs for iphones via SCEP in ejbCA and Dogtag (pki-ca 9.0.3-30 package). Dogtag wins provided we can carry on using standalone CA services in the future for free as a part of RHEL IPA? Yes this is a clear winner keeping in mind that we had some distant plans about the use case you are describing. Unfortunately we were not able to get a good understanding of the details of the use case in the past thus so many questions. Sorry. [OA] That?s cool, it seems you?ve got it right? We would like to help you as much as possible with what we have now and give you a clear migration path for the solutions we are building. This is why Dogtag 10+ and IPA 3.2+ is probably the best starting point. Thanks Dmitri Thanks, Oleg From: Dmitri Pal [mailto:dpal at redhat.com] Sent: 04 October 2013 16:54 To: Oleg Antonenko Cc: Nathan Kinder (nkinder at redhat.com); Ciaran Bradley; pki-users at redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/04/2013 11:48 AM, Oleg Antonenko wrote: Hi Dmitri, Nathan, Thank you for speedy responses. Could you please confirm my understanding? RHCS is going to be shipped as a part of RHEL7.x in the foreseeable future; It is not "a part" it is a stand alone product and not free. IPA is a free part of RHEL 6.x and will remain as such in the foreseeable future; Correct and same is true for RHEL7.x RHEL 6.x does not ship RHCS, but includes only pki-ca packages in order to support IPA. Correct Could you also clarify your point here ? The CA portion in RHEL is not supported by Red Hat for standalone use without an entitlement for the rest of RHCS, which isn't available on RHEL 6 RHCS is a layered product and can be acquired separately. We do not ship a version of RHCS on top of RHEL6. It is a big product and takes a lot of time to deliver. We decided to skip a major RHEL version. Does it mean RHCS is not free? Correct. Regarding this - We would be actually very interested if we can support this use case with core IPA. Would you be interested in a conversation about this? Yes, we?d love to. Ok let us have one. I am sorry, I have not been following the whole thread, just this mail caught my eye so what kind of functionality we are looking for? Can you formulate a "wish list" for your use case assuming the CA is a part of IPA? Many thanks, Oleg From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: 04 October 2013 16:21 To: pki-users at redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 10/04/2013 11:08 AM, Oleg Antonenko wrote: Hi Nathan, Could you please shed some light on the future plans for the pki-ca portion of RHEL? Will it be included in the standard RHEL distribution in the future? Dogtag 10+ will become a RHSC product on top of RHEL7.x Some of its portions will be gradually included into IPA that comes for free with RHEL. IMO full blown IPA is not that "full blown" in this case. We would be actually very interested if we can support this use case with core IPA. Would you be interested in a conversation about this? Thanks Dmitri I?m asking because we?re planning to use the CA bit only for issuing certificates to mobile devices via SCEP. We do not require any other services or the full blown IPA? With thanks, Oleg From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Nathan Kinder Sent: 27 September 2013 20:03 To: pki-users at redhat.com Subject: Re: [Pki-users] will the new version of RHCS support RHEL6? On 09/26/2013 10:25 PM, ? ? wrote: Hi all, I'm a beginner of the dogtag certificate system, dogtag?RHCS?is a wonderful project, but I'm confused about RHCS, could you give any help? The latest version of RHCS is 8.1, which is based on dogtag 8.1, it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included without the other 5 subsystems, could you show me the consideration why RHCS do not support RHEL6? Is RHEL6 not secure enough or some other reasons? It was simply not a targeted platform (nor are there plans to release it there). The pki-ca portion is included for use by IdM (based on the FreeIPA project). Thanks, -NGK Regards. An Yang _______________________________________________ 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 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Mon Oct 7 20:38:47 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 07 Oct 2013 13:38:47 -0700 Subject: [Pki-users] will the new version of RHCS support RHEL6? In-Reply-To: <34A5A0661B86944184C25952A4F1699086920680@Exchange-AMS.adaptivemobile.com> References: <5245D666.8030508@redhat.com> <34A5A0661B86944184C25952A4F1699086920210@Exchange-AMS.adaptivemobile.com> <524EDCDC.9080802@redhat.com> <34A5A0661B86944184C25952A4F16990869204E7@Exchange-AMS.adaptivemobile.com> <524EE4B2.1010901@redhat.com> <34A5A0661B86944184C25952A4F1699086920502@Exchange-AMS.adaptivemobile.com> <524EFE64.3090803@redhat.com> <524F03C3.4080209@redhat.com> <524F0AFC.9020700@redhat.com> <524F1C87.2010708@redhat.com> <34A5A0661B86944184C25952A4F16990869205EF@Exchange-AMS.adaptivemobile.com> <5252B786.2080201@redhat.com> <34A5A0661B86944184C25952A4F1699086920680@Exchange-AMS.adaptivemobile.com> Message-ID: <52531BD7.1050203@redhat.com> On 10/07/2013 06:58 AM, Oleg Antonenko wrote: > > Thanks Dmitri. > > It would be nice to get a confirmation from Nathan regarding p7/p10 > signing/encryption when dogtag processes SCEP requests. > Dogtag does expect PKCS#7 signed-data that is used for the SCEP pkiMessage. The signed data in the pkiMessage itself is also PKCS#7, which is the SCEP pkcsPKIEnvelope. The contents of this PKCS#7 envelope is the encrypted PKCS#10, which is the actual SCEP message itself. Perhaps you were looking at the PKCS#7 envelope for the signature instead of the PKCS#7 that is the pkiMessage? > > Here I just wanted to clarify some pointers on Cert Profiles. > > The trick might be to add additional profile to IPA CA after IPA > installation and use that profile instead of the default one in SCEP > requests. > > Yes, getting the profile set up would be then main thing to tackle. > > [OA] Could you give me a bit more insight what is advantage/why to use > an additional SCEP profile? > It depends what you want your issued certificates to look like. Dogtag only supports a single profile for SCEP currently, so you will need to look at it to see if it meets your needs as is. If it doesn't, you might need to tweak it. > > > Cert profile is a template for issuing certs. > Dogtag allows you to have more than a single template. > This makes possible to issue certs containing different contents and > used for different purposes: VPN, authentication, message signing etc. > IPA installs just one profile. I suspect that mobile devices would > need to have certs with specific attributes in them. For that you > would need to either modify the existing profile or add another one. > Latest versions of Dogtag CA have REST API to manage these profiles > programmatically but this capability is not integrated into IPA yet. > So with existing IPA version you would need to either modify existing > profile or add a new one manually. > > /[OA-2] / > > /This is a desirable option. We did not explore the current dogtag 9.0 > UI much, so I?m sorry if this is trivial. Does this UI provide a > function for creating/setting up new Cert Profiles? / > Here is some general info on certificate profiles: https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Certificate_Profiles.html#about-certificate-profiles Profiles are created via the command-line, or via the graphical Console application. There are details on both of these methods here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Setting_up_Certificate_Profiles.html As mentioned above though, Dogtag only supports a single SCEP profile currently. Thanks, -NGK > > // > > If you start with latest Dogtag and version in Fedora 19 that will be > a part of RHEL7 you can probably use REST API directly and add/modify > profiles as you need. In future IPA will provide API/CLI/UI that would > wrap this REST API and allow you to mange this consistently with the > rest of the IPA objects. > > *From:*Dmitri Pal [mailto:dpal at redhat.com] > *Sent:* 07 October 2013 14:31 > *To:* Oleg Antonenko > *Cc:* Nathan Kinder; Ciaran Bradley; pki-users at redhat.com > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > On 10/07/2013 05:19 AM, Oleg Antonenko wrote: > > Hi Nathan, Dmitri, > > Thanks for the info and your comments. Please see my answers inline in > red? > > *From:*Nathan Kinder [mailto:nkinder at redhat.com] > *Sent:* 04 October 2013 20:53 > *To:* dpal at redhat.com > *Cc:* Oleg Antonenko; Ciaran Bradley; pki-users at redhat.com > > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > On 10/04/2013 11:37 AM, Dmitri Pal wrote: > > On 10/04/2013 02:06 PM, Nathan Kinder wrote: > > On 10/04/2013 10:44 AM, Dmitri Pal wrote: > > On 10/04/2013 12:12 PM, Oleg Antonenko wrote: > > That?s all clear now, thank you Dmitri! > > Regarding our wish list J > > Basically we just have evaluated ejbCA, so we want something > similar but without EJB and heavy weight app server? i.e. - > > UI for managing certs > > > Can you define workflows and actors? > > [OA] Workflow for iOS devices is well defined in the Apple?s > guide referenced below. We will be building similar for > Android -- but simpler without a Profile Server. We use an MDM > system for distributing SCEP profile/configuration to devices? > > > Who does what when to the certs? > > [OA] Device itself plays a role of a SCEP client. After > obtaining a cert devices would you use for setting up a VPN > channel. Normally we are not planning actively manage certs > for devices, except revocation. But for SSL servers we would > have to issue certs manually, and then export full keysotre > for manual deployment. > > > Are certs associated to users or to devices? > > [OA] To devices, so the CN will contain a device ID. At the > same time subjectAltName will be set to user?s email. So in > theory it would be good to manage users but that is for the > future? > > > Do you track devices in the CA or somewhere else? > > [OA] No, we will track them in our application, which will be > integrated with MDM for device enrolment and configuration > (e.g. installing our VPN Client App & setting up SCEP > Profile). So we will need the CA API only for revoking certs. > Are users enterprise users (belong to one company) or internet > users (any user from the street)? > > [OA] Enterprise > > > > > > Support SCEP & OCSP > > > Dogtag supports both. First as a protocol the second one is > the component that can be installed and turned on. > > [OA] Those are reasons for selecting it > > For SCEP do you actually need a SCEP client ? What do you use > a SEP client? > > [OA] For iOS I presume there is an embedded client? For > Android we?re developing our own. > > Are there any specific features of the SCEP protocol that are > required that are currently natively not supported by the > Dogtag CA? > [OA] There is one area I still don?t have full understanding of. > > In the SCEP specs they say that a request for a cert is a > PKCS#7 structure signed by either -- > > ?A cert issued earlier by the requested CA (re-issuance) > > ?Self-signed cert > > ?A 3^rd party cert signed by a trusted CA (e.g. a generic > transport cert) > > The P7 structure contains a P10 request encrypted with the > requested CA pub key. > > When testing issuing certs for iOS devices in dogtag our > developers had an impression that the P10 is not encrypted, > and the P7 is not signed. I?m frankly not convinced by their > words. Could you confirm please that the SCEP cert request is > processed in dogtag as above? > > > I would leave this to Nathan to confirm. > > > > > API for issuing and revoking certs (cert-based request auth is > preferrable) -- as we want to integrate out product for > revoking certs > > > The product can be given a keytab and authenticate kerberos to > the IPA. It is very simple and would be easier to accomplish. > API for managing serts for hosts and services already > available in IPA so the question is what the certs are > associated with is very important. > Also certmonger can be used for fetching certs and storing > them in the files or DBs you need. > Are you aware of certmonger? > > [OA] No, did not hear before. As I understand it has a command > line / d-bus interfaces? We need something like a WS or REST. > > > The point is that you can create a simple WS or REST server around it > very easily. > > > > It can be effectively a whole alternative solution. From your > portal you call Certmonger on the local system via CLI or > D-BUS interface and it gets a cert for you. > But I need to understand the workflow better. If you generate > he PKI pair on you portal and deliver them to a device it is a > perfect solution. If you use client side software on the > mobile platform to send the signing request then it is a > different workflow and you need to send such request to > CA.[OA] Yes, the latter? > > > I see. > > > > > > Desirable - Export a key store (including cert) as PKCS#12, > PEM (for manual deployment of certs on e.g. SSL servers). > > > When and where? During issuance or ability to later export it > from the back end store? > > [OA] For SSL serves terminating VPN connection from mobile > devices. So we would create them before and parallel to > issuing to devices? I think it?s going to be like an admin > would login into the UI, enter machine details for the cert & > key store. In response the CA would generate a keypair and > issue a cert. Then we would need to export the keystore either > as p12 or PEM file? > > > You might want to consider using IPA to mange servers and their certs. > AFAIR IPA allows you to save certs in a PEM file. > Then for the devices you will use Dogtag directly but for servers you > will leverage all the advantages of IPA. Seems like a double win. > > > As mentioned earlier we are planning to use a CA for issuing > and delivering certs to mobile devices via SCEP. > > > I am sorry I am not familiar with the details of the workflow > in this case. > Can you describe the chain of communication between mobile > device, your portal and CA and what protocols used where? > > iOS devices uses SCEP to enroll for certificates. The basic flow > is that you have a "Profile Server", which is responsible for > delivering a XML profile onto the authenticated iOS device. This > XML profile contains details on how the iOS device should contact > the CA via SCEP. When the profile is installed, the SCEP request > is made and the returned certificate is installed. There is a good > visual workflow of this process in this document: > > https://developer.apple.com/library/ios/documentation/networkinginternet/conceptual/iphoneotaconfiguration/OTASecurity/OTASecurity.html#//apple_ref/doc/uid/TP40009505-CH3-SW1 > > > > This is very helpful. > So it seems that IPA CA might be used for this as is. The certs > would just not be associeted with any specific entry and leave in > the CA storage. > Do I get it right? > > I think so.[OA] Yes, correct. Btw, what storage the CA is using? Ldap? > > > Yes. > > > > > > The trick might be to add additional profile to IPA CA after IPA > installation and use that profile instead of the default one in SCEP > requests. > > Yes, getting the profile set up would be then main thing to tackle. > > [OA] Could you give me a bit more insight what is advantage/why to use > an additional SCEP profile? > > > Cert profile is a template for issuing certs. > Dogtag allows you to have more than a single template. > This makes possible to issue certs containing different contents and > used for different purposes: VPN, authentication, message signing etc. > IPA installs just one profile. I suspect that mobile devices would > need to have certs with specific attributes in them. For that you > would need to either modify the existing profile or add another one. > Latest versions of Dogtag CA have REST API to manage these profiles > programmatically but this capability is not integrated into IPA yet. > So with existing IPA version you would need to either modify existing > profile or add a new one manually. If you start with latest Dogtag and > version in Fedora 19 that will be a part of RHEL7 you can probably use > REST API directly and add/modify profiles as you need. In future IPA > will provide API/CLI/UI that would wrap this REST API and allow you to > mange this consistently with the rest of the IPA objects. > > > > > > Since with Dogtag 10 you have REST API and CLI to add and manage those > profiles and the data is sort of orthogonal to IPA data I do not see a > reason why portal can't integrate those and use them directly. > > To clarify, profile management REST interfaces are in Dogag 10.1 (not > 10.0). Regardless, profiles can be configured without the REST > interfaces and be used directly with IPA being none the wiser. > [OA] We would configure the CA manually. API is needed for cert > revocation only. Does dogtag 9 supports REST for revocation? > > Dogtag 9 does not support any REST API. > > > > > > -NGK > > > > > > So far we managed to issue certs for iphones via SCEP in ejbCA and > Dogtag (pki-ca 9.0.3-30 package). > > Dogtag wins provided we can carry on using standalone CA services in > the future for free as a part of RHEL IPA? > > > Yes this is a clear winner keeping in mind that we had some distant > plans about the use case you are describing. Unfortunately we were not > able to get a good understanding of the details of the use case in the > past thus so many questions. Sorry. > [OA] That?s cool, it seems you?ve got it right? > > > We would like to help you as much as possible with what we have now > and give you a clear migration path for the solutions we are building. > This is why Dogtag 10+ and IPA 3.2+ is probably the best starting point. > > > > > Thanks > Dmitri > > > > Thanks, > > Oleg > > *From:*Dmitri Pal [mailto:dpal at redhat.com] > *Sent:* 04 October 2013 16:54 > *To:* Oleg Antonenko > *Cc:* Nathan Kinder (nkinder at redhat.com ); > Ciaran Bradley; pki-users at redhat.com > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > On 10/04/2013 11:48 AM, Oleg Antonenko wrote: > > Hi Dmitri, Nathan, > > Thank you for speedy responses. > > Could you please confirm my understanding? > > RHCS is going to be shipped as a part of RHEL7.x in the foreseeable > future; > > > It is not "a part" it is a stand alone product and not free. > > > > > IPA is a free part of RHEL 6.x and will remain as such in the > foreseeable future; > > > Correct and same is true for RHEL7.x > > > > > RHEL 6.x does not ship RHCS, but includes only pki-ca packages in > order to support IPA. > > > Correct > > > > > Could you also clarify your point here ? > > /The CA portion in RHEL is not supported by Red Hat for standalone use > /*/without an entitlement for the rest of RHCS/*/, which isn't > available on RHEL 6/ > > > RHCS is a layered product and can be acquired separately. > We do not ship a version of RHCS on top of RHEL6. It is a big product > and takes a lot of time to deliver. > We decided to skip a major RHEL version. > > > > > Does it mean RHCS is not free? > > > Correct. > > > > Regarding this - > > /We would be actually very interested if we can support this use case > with core IPA. > Would you be interested in a conversation about this? > > > > > / > > Yes, we?d love to. > > > Ok let us have one. > I am sorry, I have not been following the whole thread, just this mail > caught my eye so what kind of functionality we are looking for? > Can you formulate a "wish list" for your use case assuming the CA is a > part of IPA? > > > > > > Many thanks, > > Oleg > > *From:*pki-users-bounces at redhat.com > > [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* 04 October 2013 16:21 > *To:* pki-users at redhat.com > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > On 10/04/2013 11:08 AM, Oleg Antonenko wrote: > > Hi Nathan, > > Could you please shed some light on the future plans for the pki-ca > portion of RHEL? > > Will it be included in the standard RHEL distribution in the future? > > > Dogtag 10+ will become a RHSC product on top of RHEL7.x > > Some of its portions will be gradually included into IPA that comes > for free with RHEL. > IMO full blown IPA is not that "full blown" in this case. > > We would be actually very interested if we can support this use case > with core IPA. > Would you be interested in a conversation about this? > > Thanks > Dmitri > > > > > > I?m asking because we?re planning to use the CA bit only for issuing > certificates to mobile devices via SCEP. We do not require any other > services or the full blown IPA? > > With thanks, > > Oleg > > *From:*pki-users-bounces at redhat.com > > [mailto:pki-users-bounces at redhat.com] *On Behalf Of *Nathan Kinder > *Sent:* 27 September 2013 20:03 > *To:* pki-users at redhat.com > *Subject:* Re: [Pki-users] will the new version of RHCS support RHEL6? > > On 09/26/2013 10:25 PM, ? ? wrote: > > Hi all, > > I'm a beginner of the dogtag certificate system, dogtag?RHCS?is > a wonderful project, but I'm confused about RHCS, could you give > any help? > > The latest version of RHCS is 8.1, which is based on dogtag 8.1, > it supports RHEL5.8, and in RHEL6, pki-ca 9.0.3 was included > without the other 5 subsystems, could you show me the > consideration why RHCS do not support RHEL6? > Is RHEL6 not secure enough or some other reasons? > > It was simply not a targeted platform (nor are there plans to release > it there). The pki-ca portion is included for use by IdM (based on the > FreeIPA project). > > Thanks, > -NGK > > > > > > > Regards. > An Yang > > > > > > > > _______________________________________________ > 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 > > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From awnuk at redhat.com Tue Oct 8 18:32:48 2013 From: awnuk at redhat.com (Andrew Wnuk) Date: Tue, 08 Oct 2013 11:32:48 -0700 Subject: [Pki-users] CA Administrator of Instance pki-ca In-Reply-To: <574459158D85E14CBBA091C8AD9B44E27B34EFDF65@ms03.GS.TLG.PRIVATE> References: <574459158D85E14CBBA091C8AD9B44E27B34EFEECF@ms03.GS.TLG.PRIVATE>, <524DA3EE.3080605@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B34EFDF65@ms03.GS.TLG.PRIVATE> Message-ID: <52544FD0.2060103@redhat.com> On 10/07/2013 11:41 AM, Richard Thomas wrote: > Hi Andrew, > > Thanks very much for sending this to me. > > The first thing I'd like to point out is that I'm using the pre-Red Hat enterprise variant of DogTag (dogtag-pki-1.3.0-2.el5) > > I have been trying to adapt the instructions as best I can and have so nearly got there, but not quite.. > > I have been referring to chapter 4.8.2 of that article by going to the :9444/ca/ee/ca URL and the only 2 Certificate Profiles I have to choose from are: > o) Renewal: Renew certificate to be manually approved by agents > o) Cisco VPN Client Enrolment > > The second option is for end users of our Cisco VPN to generate new certificates with, so I don't do anything with that. > > The first option looked promising, as it asked for a certificate number, so I used the :9443/ca/agent/ca URL to find the certificate number of the current "CA Administrator of Instance pki-ca" certificate, make a note of it and enter it into the certificate renewal page. > > I then use the :9443/ca/agent/ca URL to approve my request. > > Back to the :9444/ca/ee/ca URL to retrieve the certificate. > > I then updated the .p12 (.pfx) certificate with the one that appeared from the step above, with quite a bit of open_ssl commands, but I am confident that my new .p12 has everything in it as before (including the private key), with the exception of the "CA Administrator of Instance pki-ca" certificate being my updated one instead of the current one. > > I manage to import it into by machine's browser and when I navigate to :9443/ca/agent/ca, the new certificate comes up as an option to present to Dog Tag, so things are looking good at this stage and I select it. > > After that is where the first thing looks different, but I wasn't too worried about. I get a message saying "Request For Permission to Use a Key", so I grant permission. > > Then things don't look go at all, as once I'm past that, all the pages say "Invalid Credential". > > I have probably gone about things in a way that's more complicated than it should be and I guess it's because I'm using an earlier version of Dog Tag. > > Do you have any ideas where I have gone wrong with this please. > > Thank you very much. > > Richard. Unfortunately your version is old enough to miss new renewal profiles, which would make your task easier. Here is a simple way to renew your CA administrator certificate: 1. Go to EE interface (typically https://:9444/ca/ee/ca/) and select "Manual User Dual-Use Certificate Enrollment" 2. Fill out the form and submit request 3. Go to Agent interface (typically https://:9443/ca/agent/ca/) and approve submitted request 4. Return to EE interface, select "Retrieval" tab and "Check Request Status". 5. Type in request number and press submit. 6. Click on issued certificate serial number. 7. Go to the end of page displaying certificate and press "Import Your Certificate" 8. Start pkiconsole (typically by running "pkiconsole https://`hostname`:9445/ca") 9. Select "Users and Groups" and select your admin entry. 10. Press "Certificates" button then "Import" and paste in your new base64 encoded certificate, then OK and "Done" 11. Clear SSL cache in the browser or restart your browser. 12. You should now be able to use your new certificate to access Agent interface Thanks, Andrew > > ________________________________________ > From: pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] On Behalf Of Andrew Wnuk [awnuk at redhat.com] > Sent: Thursday, October 03, 2013 6:05 PM > To: pki-users at redhat.com > Subject: Re: [Pki-users] CA Administrator of Instance pki-ca > > Hi Richard, > > You can renew certificate using: https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/renewing-certificates.html > and then add new certificate to CA administrator entry using console. > > Best, > Andrew > > On 10/03/2013 08:49 AM, Richard Thomas wrote: > Hi all, > > I hope someone would be able to help me with this. > > I have taken over a Dog Tag system and I have little knowledge of it. > > I need to renew the ?CA Administrator of Instance pki-ca? certificate, as it is running out in a few weeks. > > Would someone be able to point me in the direction of any documentation on how to do this or let me know how to do it. > > I would massively appreciate any guidance on this. > > Thanks in advance, > > Richard. > > The world?s first PCI accreditation for a Point to Point Encryption application. Find out more? > The Logic Group > Enterprises Limited > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom phone > fax > email > web +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com Registered in England > Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 > > The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. > > > > > > _______________________________________________ > 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 anyang at waycooler.co Wed Oct 9 08:21:22 2013 From: anyang at waycooler.co (An Yang) Date: Wed, 09 Oct 2013 16:21:22 +0800 Subject: [Pki-users] Could RHCS81 run under RHEL59? In-Reply-To: <1380548008.2851.31.camel@aleeredhat.laptop> References: <1380548008.2851.31.camel@aleeredhat.laptop> Message-ID: <1381306882.3781.4.camel@chinese-laptop> Sorry for my lated response. > Please open a bugzilla and attach the stack trace. Please indicate the > versions of pki-ca, pki-common and tomcat. filed (id=1017032) > > This sounds like an update may be needed to the Java security policy. > In the meantime, to get the server to start, you can disable the Java > security manager by editing /etc/sysconfig/pki-ca and setting: > > SECURITY_MANAGER="false" service pki-ca start_sans_security_manager works. > > Ade > -------------- next part -------------- An HTML attachment was scrubbed... URL: From awnuk at redhat.com Fri Oct 11 23:47:20 2013 From: awnuk at redhat.com (Andrew Wnuk) Date: Fri, 11 Oct 2013 16:47:20 -0700 Subject: [Pki-users] CA Administrator of Instance pki-ca In-Reply-To: <574459158D85E14CBBA091C8AD9B44E27B3665AEA5@ms03.GS.TLG.PRIVATE> References: <574459158D85E14CBBA091C8AD9B44E27B34EFEECF@ms03.GS.TLG.PRIVATE>, <524DA3EE.3080605@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B34EFDF65@ms03.GS.TLG.PRIVATE> <52544E1C.2010308@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AEA5@ms03.GS.TLG.PRIVATE> Message-ID: <52588E08.2010803@redhat.com> On 10/11/2013 07:04 AM, Richard Thomas wrote: > > Hi Andrew, > > Thanks for those tips, I had some success, then difficulty and then > success. > > Below is what I did, with some of my comments inline. > > Before I get to that though, there are some other certificates that > are due to run out soon, but I think they should be easier to renew. > > The Common Name of those other certificates are: > > o) CN=OCSP Signing Certificate > > o) CN= > > o) CN=CA Subsystem Certificate > > o) CN=CA Audit Signing Certificate > As I noticed below, that your server provides option to "Renew certificate to be manually approved by agents". You should used this option for all your renewals. Then start pkiconsole go to "System Keys and Certificates", select "Local Certificates", click on "Add/Renew", "Next" and "Install a certificate" > Please could you help me and let me know what steps I should take for > renewing these too. > > Thank you. > > Anyway, back to what I did to get the admin certificate updated. > > Your steps are still numbered, the ones that I did around them are > identified with o) > > Here goes: > > o) Edit /var/lib/pki-ca/profiles/ca/caUserCert.cfg > > Change: > > visible=false > > enable=false > > To: > > visible=true > > enable=true > > o) Restart service "pki-cad" > > 1. Go to EE interface (typically > https://:9444/ca/ee/ca/) and select "Manual User Dual-Use > Certificate Enrollment" > > 2. Fill out the form and submit request > > 3. Go to Agent interface (typically > https://:9443/ca/agent/ca/) and approve submitted request > > 4. Return to EE interface, select "Retrieval" tab and > "Check Request Status". > > 5. Type in request number and press submit. > > 6. Click on issued certificate serial number. > > >I did "List Certificates", went to the last page and found the certificate that way > > 7. Go to the end of page displaying certificate and press > "Import Your Certificate" > > >I got "The server returned an invalid client certificate. Error 207 (net::ERR_CERT_INVALID)" > This probably means that browser which generated certificate request (and the key) is not the same browser used to import certificate. > > So having got stuck at this point, I figured I could use what I had done before and then use your > pkiconsole instructions. > > > The below is end-to-end from what I started off on my own and then across to the second half of your > instructions. > > o) Go to the :9444/ca/ee/ca URL > > o) Click on "Renewal: Renew certificate to be manually approved by > agents" (make a note of the number) > > o) Go to the :9443/ca/agent/ca URL to approve my request. (Use > the number above) > > o) Go to the :9444/ca/ee/ca URL to retrieve the certificate. > (Use the number above) and click on the Issued certificate > > o) Extract the Base 64 encoded part of the certificate and save as > .pem > > o) Transfer .p12 and name>.pem to a machine with openssl installed on it > > o) On a machine with openssl installed on it, submit following command: > > $openssl pkcs12 -in .p12 -out certificate bundle name>.pem -nodes > > o) Copy .pem to name>.pem > > o) Update .pem by replacing the relevant > part of it with the contents of .pem > > o) Cut the key part of .pem and create > .key from it > > o) Submit following command: > > $openssl pkcs12 -export -in .pem -inkey > .key -out .p12 > > o) Transfer .p12 to the machine with the > web browser that you want to access Dog Tag from. > > o) Import .p12 into the machine. > > 8. Start pkiconsole (typically by running "pkiconsole > https://`hostname`:9445/ca") > > 9. Select "Users and Groups" and select your admin entry. > > 10. Press "Certificates" button then "Import" and paste in > the contents of .pem, then OK and "Done" > > 11. Clear SSL cache in the browser or restart your browser. > > 12. You should now be able to use your new certificate to > access Agent interface > > >YES -- I can now access the agent interface using the new certificate J > > *From:*Andrew Wnuk [mailto:awnuk at redhat.com] > *Sent:* 08 October 2013 19:26 > *To:* Richard Thomas > *Cc:* pki-users-bounces at redhat.com > *Subject:* Re: [Pki-users] CA Administrator of Instance pki-ca > > On 10/07/2013 11:41 AM, Richard Thomas wrote: > > Hi Andrew, > > > > Thanks very much for sending this to me. > > > > The first thing I'd like to point out is that I'm using the pre-Red Hat enterprise variant of DogTag (dogtag-pki-1.3.0-2.el5) > > > > I have been trying to adapt the instructions as best I can and have so nearly got there, but not quite.. > > > > I have been referring to chapter 4.8.2 of that article by going to the :9444/ca/ee/ca URL and the only 2 Certificate Profiles I have to choose from are: > > o) Renewal: Renew certificate to be manually approved by agents > > o) Cisco VPN Client Enrolment > > > > The second option is for end users of our Cisco VPN to generate new certificates with, so I don't do anything with that. > > > > The first option looked promising, as it asked for a certificate number, so I used the :9443/ca/agent/ca URL to find the certificate number of the current "CA Administrator of Instance pki-ca" certificate, make a note of it and enter it into the certificate renewal page. > > > > I then use the :9443/ca/agent/ca URL to approve my request. > > > > Back to the :9444/ca/ee/ca URL to retrieve the certificate. > > > > I then updated the .p12 (.pfx) certificate with the one that appeared from the step above, with quite a bit of open_ssl commands, but I am confident that my new .p12 has everything in it as before (including the private key), with the exception of the "CA Administrator of Instance pki-ca" certificate being my updated one instead of the current one. > > > > I manage to import it into by machine's browser and when I navigate to :9443/ca/agent/ca, the new certificate comes up as an option to present to Dog Tag, so things are looking good at this stage and I select it. > > > > After that is where the first thing looks different, but I wasn't too worried about. I get a message saying "Request For Permission to Use a Key", so I grant permission. > > > > Then things don't look go at all, as once I'm past that, all the pages say "Invalid Credential". > > > > I have probably gone about things in a way that's more complicated than it should be and I guess it's because I'm using an earlier version of Dog Tag. > > > > Do you have any ideas where I have gone wrong with this please. > > > > Thank you very much. > > > > Richard. > > > > > Unfortunately your version is old enough to miss new renewal profiles, > which would make your task easier. > > Here is a simple way to renew your CA administrator certificate: > > 1. Go to EE interface (typically https://:9444/ca/ee/ca/) > and select "Manual User Dual-Use Certificate Enrollment" > 2. Fill out the form and submit request > 3. Go to Agent interface (typically > https://:9443/ca/agent/ca/) and approve submitted request > 4. Return to EE interface, select "Retrieval" tab and "Check Request > Status". > 5. Type in request number and press submit. > 6. Click on issued certificate serial number. > 7. Go to the end of page displaying certificate and press "Import > Your Certificate" > 8. Start pkiconsole (typically by running "pkiconsole > https://`hostname`:9445/ca") > 9. Select "Users and Groups" and select your admin entry. > 10. Press "Certificates" button then "Import" and paste in your new > base64 encoded certificate, then OK and "Done" > 11. Clear SSL cache in the browser or restart your browser. > 12. You should now be able to use your new certificate to access Agent > interface > > Thanks, > Andrew > > > > > ________________________________________ > From:pki-users-bounces at redhat.com [pki-users-bounces at redhat.com ] On Behalf Of Andrew Wnuk [awnuk at redhat.com ] > Sent: Thursday, October 03, 2013 6:05 PM > To:pki-users at redhat.com > Subject: Re: [Pki-users] CA Administrator of Instance pki-ca > > Hi Richard, > > You can renew certificate using:https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/renewing-certificates.html > and then add new certificate to CA administrator entry using console. > > Best, > Andrew > > On 10/03/2013 08:49 AM, Richard Thomas wrote: > Hi all, > > I hope someone would be able to help me with this. > > I have taken over a Dog Tag system and I have little knowledge of it. > > I need to renew the "CA Administrator of Instance pki-ca" certificate, as it is running out in a few weeks. > > Would someone be able to point me in the direction of any documentation on how to do this or let me know how to do it. > > I would massively appreciate any guidance on this. > > Thanks in advance, > > Richard. > > The world's first PCI accreditation for a Point to Point Encryption application. Find out more... > The Logic Group > Enterprises Limited > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom phone > fax > email > web +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com Registered in England > Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 > > The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. > > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > > > *The world's first PCI accreditation for a Point to Point Encryption > application.**Find out more... > > * > > The Logic Group > Enterprises Limited > > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom phone > fax > email > web +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com Registered in England > Number 2609323 > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business > Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered > No. 2609323 > > The information in this email and any attachments are confidential and > may be legally privileged and protected by law. It is for the intended > recipient only. If you are not the intended recipient you may not use, > disclose, copy, distribute, print or rely on the content of this email > or its attachments. If this email has been received by you in error > please advise the sender and delete the email from your system. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Richard.Thomas at the-logic-group.com Tue Oct 15 09:35:51 2013 From: Richard.Thomas at the-logic-group.com (Richard Thomas) Date: Tue, 15 Oct 2013 10:35:51 +0100 Subject: [Pki-users] CA Administrator of Instance pki-ca In-Reply-To: <52588E08.2010803@redhat.com> References: <574459158D85E14CBBA091C8AD9B44E27B34EFEECF@ms03.GS.TLG.PRIVATE>, <524DA3EE.3080605@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B34EFDF65@ms03.GS.TLG.PRIVATE> <52544E1C.2010308@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AEA5@ms03.GS.TLG.PRIVATE> <52588E08.2010803@redhat.com> Message-ID: <574459158D85E14CBBA091C8AD9B44E27B3665AED7@ms03.GS.TLG.PRIVATE> Hi Andrew, Thanks again for getting back to me. Unfortunately, I didn't get very far. I've shown below what I have done and what it resulted in: o) Go to the :9443/ca/agent/ca URL and list the certificates stored in Dogtag. o) Make a note of of the Certificate Serial Numbers of the following certificates and change the hex value into decimal: CN=OCSP Signing Certificate E.G. 2 CN= E.G. 3 CN=CA Subsystem Certificate E.G. 4 CN=CA Audit Signing Certificate E.G. 5 CN= E.G. 268369921 o) Go to the :9444/ca/ee/ca URL o) Click on "Renewal: Renew certificate to be manually approved by agents" o) Submit each of the Certificate Serial Numbers noted above and make a note of the request ID For each Certificate Serial Number listed above that I submit, I get the following: Sorry, your request is not submitted. The reason is "Profile caServerCert Not Found". Please could you help me further. Many thanks. Richard. From: Andrew Wnuk [mailto:awnuk at redhat.com] Sent: 12 October 2013 00:47 To: Richard Thomas Cc: pki-users at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca On 10/11/2013 07:04 AM, Richard Thomas wrote: Hi Andrew, Thanks for those tips, I had some success, then difficulty and then success. Below is what I did, with some of my comments inline. Before I get to that though, there are some other certificates that are due to run out soon, but I think they should be easier to renew. The Common Name of those other certificates are: o) CN=OCSP Signing Certificate o) CN= o) CN=CA Subsystem Certificate o) CN=CA Audit Signing Certificate As I noticed below, that your server provides option to "Renew certificate to be manually approved by agents". You should used this option for all your renewals. Then start pkiconsole go to "System Keys and Certificates", select "Local Certificates", click on "Add/Renew", "Next" and "Install a certificate" Please could you help me and let me know what steps I should take for renewing these too. Thank you. Anyway, back to what I did to get the admin certificate updated. Your steps are still numbered, the ones that I did around them are identified with o) Here goes: o) Edit /var/lib/pki-ca/profiles/ca/caUserCert.cfg Change: visible=false enable=false To: visible=true enable=true o) Restart service "pki-cad" 1. Go to EE interface (typically https://:9444/ca/ee/ca/) and select "Manual User Dual-Use Certificate Enrollment" 2. Fill out the form and submit request 3. Go to Agent interface (typically https://:9443/ca/agent/ca/) and approve submitted request 4. Return to EE interface, select "Retrieval" tab and "Check Request Status". 5. Type in request number and press submit. 6. Click on issued certificate serial number. >I did "List Certificates", went to the last page and found the certificate that way 7. Go to the end of page displaying certificate and press "Import Your Certificate" >I got "The server returned an invalid client certificate. Error 207 (net::ERR_CERT_INVALID)" This probably means that browser which generated certificate request (and the key) is not the same browser used to import certificate. > So having got stuck at this point, I figured I could use what I had done before and then use your pkiconsole instructions. > The below is end-to-end from what I started off on my own and then across to the second half of your instructions. o) Go to the :9444/ca/ee/ca URL o) Click on "Renewal: Renew certificate to be manually approved by agents" (make a note of the number) o) Go to the :9443/ca/agent/ca URL to approve my request. (Use the number above) o) Go to the :9444/ca/ee/ca URL to retrieve the certificate. (Use the number above) and click on the Issued certificate o) Extract the Base 64 encoded part of the certificate and save as .pem o) Transfer .p12 and .pem to a machine with openssl installed on it o) On a machine with openssl installed on it, submit following command: $openssl pkcs12 -in .p12 -out .pem -nodes o) Copy .pem to .pem o) Update .pem by replacing the relevant part of it with the contents of .pem o) Cut the key part of .pem and create .key from it o) Submit following command: $openssl pkcs12 -export -in .pem -inkey .key -out .p12 o) Transfer .p12 to the machine with the web browser that you want to access Dog Tag from. o) Import .p12 into the machine. 8. Start pkiconsole (typically by running "pkiconsole https://`hostname`:9445/ca") 9. Select "Users and Groups" and select your admin entry. 10. Press "Certificates" button then "Import" and paste in the contents of .pem, then OK and "Done" 11. Clear SSL cache in the browser or restart your browser. 12. You should now be able to use your new certificate to access Agent interface >YES - I can now access the agent interface using the new certificate J From: Andrew Wnuk [mailto:awnuk at redhat.com] Sent: 08 October 2013 19:26 To: Richard Thomas Cc: pki-users-bounces at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca On 10/07/2013 11:41 AM, Richard Thomas wrote: Hi Andrew, Thanks very much for sending this to me. The first thing I'd like to point out is that I'm using the pre-Red Hat enterprise variant of DogTag (dogtag-pki-1.3.0-2.el5) I have been trying to adapt the instructions as best I can and have so nearly got there, but not quite.. I have been referring to chapter 4.8.2 of that article by going to the :9444/ca/ee/ca URL and the only 2 Certificate Profiles I have to choose from are: o) Renewal: Renew certificate to be manually approved by agents o) Cisco VPN Client Enrolment The second option is for end users of our Cisco VPN to generate new certificates with, so I don't do anything with that. The first option looked promising, as it asked for a certificate number, so I used the :9443/ca/agent/ca URL to find the certificate number of the current "CA Administrator of Instance pki-ca" certificate, make a note of it and enter it into the certificate renewal page. I then use the :9443/ca/agent/ca URL to approve my request. Back to the :9444/ca/ee/ca URL to retrieve the certificate. I then updated the .p12 (.pfx) certificate with the one that appeared from the step above, with quite a bit of open_ssl commands, but I am confident that my new .p12 has everything in it as before (including the private key), with the exception of the "CA Administrator of Instance pki-ca" certificate being my updated one instead of the current one. I manage to import it into by machine's browser and when I navigate to :9443/ca/agent/ca, the new certificate comes up as an option to present to Dog Tag, so things are looking good at this stage and I select it. After that is where the first thing looks different, but I wasn't too worried about. I get a message saying "Request For Permission to Use a Key", so I grant permission. Then things don't look go at all, as once I'm past that, all the pages say "Invalid Credential". I have probably gone about things in a way that's more complicated than it should be and I guess it's because I'm using an earlier version of Dog Tag. Do you have any ideas where I have gone wrong with this please. Thank you very much. Richard. Unfortunately your version is old enough to miss new renewal profiles, which would make your task easier. Here is a simple way to renew your CA administrator certificate: 1. Go to EE interface (typically https://:9444/ca/ee/ca/) and select "Manual User Dual-Use Certificate Enrollment" 2. Fill out the form and submit request 3. Go to Agent interface (typically https://:9443/ca/agent/ca/) and approve submitted request 4. Return to EE interface, select "Retrieval" tab and "Check Request Status". 5. Type in request number and press submit. 6. Click on issued certificate serial number. 7. Go to the end of page displaying certificate and press "Import Your Certificate" 8. Start pkiconsole (typically by running "pkiconsole https://`hostname`:9445/ca") 9. Select "Users and Groups" and select your admin entry. 10. Press "Certificates" button then "Import" and paste in your new base64 encoded certificate, then OK and "Done" 11. Clear SSL cache in the browser or restart your browser. 12. You should now be able to use your new certificate to access Agent interface Thanks, Andrew ________________________________________ From: pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] On Behalf Of Andrew Wnuk [awnuk at redhat.com] Sent: Thursday, October 03, 2013 6:05 PM To: pki-users at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca Hi Richard, You can renew certificate using: https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/renewing-certificates.html and then add new certificate to CA administrator entry using console. Best, Andrew On 10/03/2013 08:49 AM, Richard Thomas wrote: Hi all, I hope someone would be able to help me with this. I have taken over a Dog Tag system and I have little knowledge of it. I need to renew the "CA Administrator of Instance pki-ca" certificate, as it is running out in a few weeks. Would someone be able to point me in the direction of any documentation on how to do this or let me know how to do it. I would massively appreciate any guidance on this. Thanks in advance, Richard. The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From awnuk at redhat.com Tue Oct 15 16:41:28 2013 From: awnuk at redhat.com (Andrew Wnuk) Date: Tue, 15 Oct 2013 09:41:28 -0700 Subject: [Pki-users] CA Administrator of Instance pki-ca In-Reply-To: <574459158D85E14CBBA091C8AD9B44E27B3665AED7@ms03.GS.TLG.PRIVATE> References: <574459158D85E14CBBA091C8AD9B44E27B34EFEECF@ms03.GS.TLG.PRIVATE>, <524DA3EE.3080605@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B34EFDF65@ms03.GS.TLG.PRIVATE> <52544E1C.2010308@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AEA5@ms03.GS.TLG.PRIVATE> <52588E08.2010803@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AED7@ms03.GS.TLG.PRIVATE> Message-ID: <525D7038.4010206@redhat.com> On 10/15/2013 02:35 AM, Richard Thomas wrote: > > Hi Andrew, > > Thanks again for getting back to me. > > Unfortunately, I didn't get very far. > > I've shown below what I have done and what it resulted in: > > o) Go to the :9443/ca/agent/ca URL and list the certificates > stored in Dogtag. > > o) Make a note of of the Certificate Serial Numbers of the following > certificates and change the hex value into decimal: > > CN=OCSP Signing Certificate E.G. 2 > > CN= E.G. 3 > > CN=CA Subsystem Certificate E.G. 4 > > CN=CA Audit Signing Certificate E.G. 5 > > CN= E.G. 268369921 > > o) Go to the :9444/ca/ee/ca URL > > o) Click on "Renewal: Renew certificate to be manually approved by agents" > > o) Submit each of the Certificate Serial Numbers noted above and make > a note of the request ID > > For each Certificate Serial Number listed above that I submit, I get > the following: > > Sorry, your request is not submitted. The reason is "Profile > caServerCert Not Found". > Check if caServerCert.cfg is listed under /var/lib/pki-ca/profiles/ca and then check if /var/lib/pki-ca/conf/CS.cfg includes profile.list= . . . ,caServerCert, . . . . . . profile.caServerCert.class_id=caEnrollImpl profile.caServerCert.config=/var/lib/pki-ca/profiles/ca/caServerCert.cfg . . . > Please could you help me further. > > Many thanks. > > Richard. > > *From:*Andrew Wnuk [mailto:awnuk at redhat.com] > *Sent:* 12 October 2013 00:47 > *To:* Richard Thomas > *Cc:* pki-users at redhat.com > *Subject:* Re: [Pki-users] CA Administrator of Instance pki-ca > > On 10/11/2013 07:04 AM, Richard Thomas wrote: > > Hi Andrew, > > Thanks for those tips, I had some success, then difficulty and > then success. > > Below is what I did, with some of my comments inline. > > Before I get to that though, there are some other certificates > that are due to run out soon, but I think they should be easier to > renew. > > The Common Name of those other certificates are: > > o) CN=OCSP Signing Certificate > > o) CN= > > o) CN=CA Subsystem Certificate > > o) CN=CA Audit Signing Certificate > > > As I noticed below, that your server provides option to "Renew > certificate to be manually approved by agents". > You should used this option for all your renewals. > > Then start pkiconsole go to "System Keys and Certificates", select > "Local Certificates", click on "Add/Renew", "Next" and "Install a > certificate" > > > Please could you help me and let me know what steps I should take for > renewing these too. > > Thank you. > > Anyway, back to what I did to get the admin certificate updated. > > Your steps are still numbered, the ones that I did around them are > identified with o) > > Here goes: > > o) Edit /var/lib/pki-ca/profiles/ca/caUserCert.cfg > > Change: > > visible=false > > enable=false > > To: > > visible=true > > enable=true > > o) Restart service "pki-cad" > > 1. Go to EE interface (typically > https://:9444/ca/ee/ca/) and select "Manual User Dual-Use > Certificate Enrollment" > > 2. Fill out the form and submit request > > 3. Go to Agent interface (typically > https://:9443/ca/agent/ca/) and approve submitted request > > 4. Return to EE interface, select "Retrieval" tab and "Check Request > Status". > > 5. Type in request number and press submit. > > 6. Click on issued certificate serial number. > > >I did "List Certificates", went to the last page and found the certificate that way > > 7. Go to the end of page displaying certificate and press > "Import Your Certificate" > > >I got "The server returned an invalid client certificate. Error 207 > (net::ERR_CERT_INVALID)" > > > This probably means that browser which generated certificate request > (and the key) is not the same browser used to import certificate. > > > > So having got stuck at this point, I figured I could use what I had done before and > then use your pkiconsole instructions. > > > The below is end-to-end from what I started off on my own and then across to the > second half of your instructions. > > o) Go to the :9444/ca/ee/ca URL > > o) Click on "Renewal: Renew certificate to be manually approved by > agents" (make a note of the number) > > o) Go to the :9443/ca/agent/ca URL to approve my request. (Use > the number above) > > o) Go to the :9444/ca/ee/ca URL to retrieve the certificate. > (Use the number above) and click on the Issued certificate > > o) Extract the Base 64 encoded part of the certificate and save as > .pem > > o) Transfer .p12 and name>.pem to a machine with openssl installed on it > > o) On a machine with openssl installed on it, submit following command: > > $openssl pkcs12 -in .p12 -out certificate bundle name>.pem -nodes > > o) Copy .pem to name>.pem > > o) Update .pem by replacing the relevant > part of it with the contents of .pem > > o) Cut the key part of .pem and create > .key from it > > o) Submit following command: > > $openssl pkcs12 -export -in .pem -inkey > .key -out .p12 > > o) Transfer .p12 to the machine with the > web browser that you want to access Dog Tag from. > > o) Import .p12 into the machine. > > 8. Start pkiconsole (typically by running "pkiconsole > https://`hostname`:9445/ca") > > 9. Select "Users and Groups" and select your admin entry. > > 10. Press "Certificates" button then "Import" and paste in > the contents of .pem, then OK and "Done" > > 11. Clear SSL cache in the browser or restart your browser. > > 12. You should now be able to use your new certificate to > access Agent interface > > >YES -- I can now access the agent interface using the new certificate J > > *From:*Andrew Wnuk [mailto:awnuk at redhat.com] > *Sent:* 08 October 2013 19:26 > *To:* Richard Thomas > *Cc:* pki-users-bounces at redhat.com > *Subject:* Re: [Pki-users] CA Administrator of Instance pki-ca > > On 10/07/2013 11:41 AM, Richard Thomas wrote: > > Hi Andrew, > > > > Thanks very much for sending this to me. > > > > The first thing I'd like to point out is that I'm using the pre-Red Hat enterprise variant of DogTag (dogtag-pki-1.3.0-2.el5) > > > > I have been trying to adapt the instructions as best I can and have so nearly got there, but not quite.. > > > > I have been referring to chapter 4.8.2 of that article by going to the :9444/ca/ee/ca URL and the only 2 Certificate Profiles I have to choose from are: > > o) Renewal: Renew certificate to be manually approved by agents > > o) Cisco VPN Client Enrolment > > > > The second option is for end users of our Cisco VPN to generate new certificates with, so I don't do anything with that. > > > > The first option looked promising, as it asked for a certificate number, so I used the :9443/ca/agent/ca URL to find the certificate number of the current "CA Administrator of Instance pki-ca" certificate, make a note of it and enter it into the certificate renewal page. > > > > I then use the :9443/ca/agent/ca URL to approve my request. > > > > Back to the :9444/ca/ee/ca URL to retrieve the certificate. > > > > I then updated the .p12 (.pfx) certificate with the one that appeared from the step above, with quite a bit of open_ssl commands, but I am confident that my new .p12 has everything in it as before (including the private key), with the exception of the "CA Administrator of Instance pki-ca" certificate being my updated one instead of the current one. > > > > I manage to import it into by machine's browser and when I navigate to :9443/ca/agent/ca, the new certificate comes up as an option to present to Dog Tag, so things are looking good at this stage and I select it. > > > > After that is where the first thing looks different, but I wasn't too worried about. I get a message saying "Request For Permission to Use a Key", so I grant permission. > > > > Then things don't look go at all, as once I'm past that, all the pages say "Invalid Credential". > > > > I have probably gone about things in a way that's more complicated than it should be and I guess it's because I'm using an earlier version of Dog Tag. > > > > Do you have any ideas where I have gone wrong with this please. > > > > Thank you very much. > > > > Richard. > > > > > Unfortunately your version is old enough to miss new renewal profiles, > which would make your task easier. > > Here is a simple way to renew your CA administrator certificate: > > 1. Go to EE interface (typically https://:9444/ca/ee/ca/) > and select "Manual User Dual-Use Certificate Enrollment" > 2. Fill out the form and submit request > 3. Go to Agent interface (typically > https://:9443/ca/agent/ca/) and approve submitted request > 4. Return to EE interface, select "Retrieval" tab and "Check Request > Status". > 5. Type in request number and press submit. > 6. Click on issued certificate serial number. > 7. Go to the end of page displaying certificate and press "Import > Your Certificate" > 8. Start pkiconsole (typically by running "pkiconsole > https://`hostname`:9445/ca") > 9. Select "Users and Groups" and select your admin entry. > 10. Press "Certificates" button then "Import" and paste in your new > base64 encoded certificate, then OK and "Done" > 11. Clear SSL cache in the browser or restart your browser. > 12. You should now be able to use your new certificate to access Agent > interface > > Thanks, > Andrew > > > > > > ________________________________________ > From:pki-users-bounces at redhat.com [pki-users-bounces at redhat.com ] On Behalf Of Andrew Wnuk [awnuk at redhat.com ] > Sent: Thursday, October 03, 2013 6:05 PM > To:pki-users at redhat.com > Subject: Re: [Pki-users] CA Administrator of Instance pki-ca > > Hi Richard, > > You can renew certificate using:https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/renewing-certificates.html > and then add new certificate to CA administrator entry using console. > > Best, > Andrew > > On 10/03/2013 08:49 AM, Richard Thomas wrote: > Hi all, > > I hope someone would be able to help me with this. > > I have taken over a Dog Tag system and I have little knowledge of it. > > I need to renew the "CA Administrator of Instance pki-ca" certificate, as it is running out in a few weeks. > > Would someone be able to point me in the direction of any documentation on how to do this or let me know how to do it. > > I would massively appreciate any guidance on this. > > Thanks in advance, > > Richard. > > The world's first PCI accreditation for a Point to Point Encryption application. Find out more... > The Logic Group > Enterprises Limited > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom phone > fax > email > web +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com Registered in England > Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 > > The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. > > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > > > *The world's first PCI accreditation for a Point to Point Encryption > application.**Find out more... > ** > * > > The Logic Group > Enterprises Limited > > > > > > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom > > > > > > phone > fax > email > web > > > > +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com > > > > > > Registered in England > Number 2609323 > > > > > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business > Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered > No. 2609323 > > The information in this email and any attachments are confidential and > may be legally privileged and protected by law. It is for the intended > recipient only. If you are not the intended recipient you may not use, > disclose, copy, distribute, print or rely on the content of this email > or its attachments. If this email has been received by you in error > please advise the sender and delete the email from your system. > > *The world's first PCI accreditation for a Point to Point Encryption > application.**Find out more... > > * > > The Logic Group > Enterprises Limited > > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom phone > fax > email > web +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com Registered in England > Number 2609323 > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business > Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered > No. 2609323 > > The information in this email and any attachments are confidential and > may be legally privileged and protected by law. It is for the intended > recipient only. If you are not the intended recipient you may not use, > disclose, copy, distribute, print or rely on the content of this email > or its attachments. If this email has been received by you in error > please advise the sender and delete the email from your system. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Richard.Thomas at the-logic-group.com Wed Oct 16 13:31:13 2013 From: Richard.Thomas at the-logic-group.com (Richard Thomas) Date: Wed, 16 Oct 2013 14:31:13 +0100 Subject: [Pki-users] CA Administrator of Instance pki-ca In-Reply-To: <525D7038.4010206@redhat.com> References: <574459158D85E14CBBA091C8AD9B44E27B34EFEECF@ms03.GS.TLG.PRIVATE>, <524DA3EE.3080605@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B34EFDF65@ms03.GS.TLG.PRIVATE> <52544E1C.2010308@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AEA5@ms03.GS.TLG.PRIVATE> <52588E08.2010803@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AED7@ms03.GS.TLG.PRIVATE> <525D7038.4010206@redhat.com> Message-ID: <574459158D85E14CBBA091C8AD9B44E27B3665AEF3@ms03.GS.TLG.PRIVATE> Hi Andrew, Thanks for your email, I got past that issue once I made some edits to some .cfg files in /var/lib/pki-ca/profiles/ca/ (shown at the bottom of this email). That meant I could get as far as "Install a certificate" and I got a choice of the following when doing so: o) Certificate Manager CA Signing Certificate(s) o) OCSP Signing Certificate(s) o) SSL Server Certificate(s) o) Cross-signed Certificate(s) o) Other Certificate(s) Please could you let me know which of the above option I should select. Thank you. Richard. Here's what I did to be able to "Renew certificate to be manually approved by agents". Edit file /var/lib/pki-ca/profiles/ca/caServerCert.cfg Change: visible=false enable=false To: visible=true enable=true Edit file /var/lib/pki-ca/profiles/ca/caOCSPCert.cfg Change: visible=false enable=false To: visible=true enable=true Edit file /var/lib/pki-ca/profiles/ca/caSignedLogCert.cfg Change: visible=false enable=false To: visible=true enable=true service pki-cad restart From: Andrew Wnuk [mailto:awnuk at redhat.com] Sent: 15 October 2013 17:41 To: Richard Thomas Cc: pki-users at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca On 10/15/2013 02:35 AM, Richard Thomas wrote: Hi Andrew, Thanks again for getting back to me. Unfortunately, I didn't get very far. I've shown below what I have done and what it resulted in: o) Go to the :9443/ca/agent/ca URL and list the certificates stored in Dogtag. o) Make a note of of the Certificate Serial Numbers of the following certificates and change the hex value into decimal: CN=OCSP Signing Certificate E.G. 2 CN= E.G. 3 CN=CA Subsystem Certificate E.G. 4 CN=CA Audit Signing Certificate E.G. 5 CN= E.G. 268369921 o) Go to the :9444/ca/ee/ca URL o) Click on "Renewal: Renew certificate to be manually approved by agents" o) Submit each of the Certificate Serial Numbers noted above and make a note of the request ID For each Certificate Serial Number listed above that I submit, I get the following: Sorry, your request is not submitted. The reason is "Profile caServerCert Not Found". Check if caServerCert.cfg is listed under /var/lib/pki-ca/profiles/ca and then check if /var/lib/pki-ca/conf/CS.cfg includes profile.list= . . . ,caServerCert, . . . . . . profile.caServerCert.class_id=caEnrollImpl profile.caServerCert.config=/var/lib/pki-ca/profiles/ca/caServerCert.cfg . . . Please could you help me further. Many thanks. Richard. From: Andrew Wnuk [mailto:awnuk at redhat.com] Sent: 12 October 2013 00:47 To: Richard Thomas Cc: pki-users at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca On 10/11/2013 07:04 AM, Richard Thomas wrote: Hi Andrew, Thanks for those tips, I had some success, then difficulty and then success. Below is what I did, with some of my comments inline. Before I get to that though, there are some other certificates that are due to run out soon, but I think they should be easier to renew. The Common Name of those other certificates are: o) CN=OCSP Signing Certificate o) CN= o) CN=CA Subsystem Certificate o) CN=CA Audit Signing Certificate As I noticed below, that your server provides option to "Renew certificate to be manually approved by agents". You should used this option for all your renewals. Then start pkiconsole go to "System Keys and Certificates", select "Local Certificates", click on "Add/Renew", "Next" and "Install a certificate" Please could you help me and let me know what steps I should take for renewing these too. Thank you. Anyway, back to what I did to get the admin certificate updated. Your steps are still numbered, the ones that I did around them are identified with o) Here goes: o) Edit /var/lib/pki-ca/profiles/ca/caUserCert.cfg Change: visible=false enable=false To: visible=true enable=true o) Restart service "pki-cad" 1. Go to EE interface (typically https://:9444/ca/ee/ca/) and select "Manual User Dual-Use Certificate Enrollment" 2. Fill out the form and submit request 3. Go to Agent interface (typically https://:9443/ca/agent/ca/) and approve submitted request 4. Return to EE interface, select "Retrieval" tab and "Check Request Status". 5. Type in request number and press submit. 6. Click on issued certificate serial number. >I did "List Certificates", went to the last page and found the certificate that way 7. Go to the end of page displaying certificate and press "Import Your Certificate" >I got "The server returned an invalid client certificate. Error 207 (net::ERR_CERT_INVALID)" This probably means that browser which generated certificate request (and the key) is not the same browser used to import certificate. > So having got stuck at this point, I figured I could use what I had done before and then use your pkiconsole instructions. > The below is end-to-end from what I started off on my own and then across to the second half of your instructions. o) Go to the :9444/ca/ee/ca URL o) Click on "Renewal: Renew certificate to be manually approved by agents" (make a note of the number) o) Go to the :9443/ca/agent/ca URL to approve my request. (Use the number above) o) Go to the :9444/ca/ee/ca URL to retrieve the certificate. (Use the number above) and click on the Issued certificate o) Extract the Base 64 encoded part of the certificate and save as .pem o) Transfer .p12 and .pem to a machine with openssl installed on it o) On a machine with openssl installed on it, submit following command: $openssl pkcs12 -in .p12 -out .pem -nodes o) Copy .pem to .pem o) Update .pem by replacing the relevant part of it with the contents of .pem o) Cut the key part of .pem and create .key from it o) Submit following command: $openssl pkcs12 -export -in .pem -inkey .key -out .p12 o) Transfer .p12 to the machine with the web browser that you want to access Dog Tag from. o) Import .p12 into the machine. 8. Start pkiconsole (typically by running "pkiconsole https://`hostname`:9445/ca") 9. Select "Users and Groups" and select your admin entry. 10. Press "Certificates" button then "Import" and paste in the contents of .pem, then OK and "Done" 11. Clear SSL cache in the browser or restart your browser. 12. You should now be able to use your new certificate to access Agent interface >YES - I can now access the agent interface using the new certificate J From: Andrew Wnuk [mailto:awnuk at redhat.com] Sent: 08 October 2013 19:26 To: Richard Thomas Cc: pki-users-bounces at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca On 10/07/2013 11:41 AM, Richard Thomas wrote: Hi Andrew, Thanks very much for sending this to me. The first thing I'd like to point out is that I'm using the pre-Red Hat enterprise variant of DogTag (dogtag-pki-1.3.0-2.el5) I have been trying to adapt the instructions as best I can and have so nearly got there, but not quite.. I have been referring to chapter 4.8.2 of that article by going to the :9444/ca/ee/ca URL and the only 2 Certificate Profiles I have to choose from are: o) Renewal: Renew certificate to be manually approved by agents o) Cisco VPN Client Enrolment The second option is for end users of our Cisco VPN to generate new certificates with, so I don't do anything with that. The first option looked promising, as it asked for a certificate number, so I used the :9443/ca/agent/ca URL to find the certificate number of the current "CA Administrator of Instance pki-ca" certificate, make a note of it and enter it into the certificate renewal page. I then use the :9443/ca/agent/ca URL to approve my request. Back to the :9444/ca/ee/ca URL to retrieve the certificate. I then updated the .p12 (.pfx) certificate with the one that appeared from the step above, with quite a bit of open_ssl commands, but I am confident that my new .p12 has everything in it as before (including the private key), with the exception of the "CA Administrator of Instance pki-ca" certificate being my updated one instead of the current one. I manage to import it into by machine's browser and when I navigate to :9443/ca/agent/ca, the new certificate comes up as an option to present to Dog Tag, so things are looking good at this stage and I select it. After that is where the first thing looks different, but I wasn't too worried about. I get a message saying "Request For Permission to Use a Key", so I grant permission. Then things don't look go at all, as once I'm past that, all the pages say "Invalid Credential". I have probably gone about things in a way that's more complicated than it should be and I guess it's because I'm using an earlier version of Dog Tag. Do you have any ideas where I have gone wrong with this please. Thank you very much. Richard. Unfortunately your version is old enough to miss new renewal profiles, which would make your task easier. Here is a simple way to renew your CA administrator certificate: 1. Go to EE interface (typically https://:9444/ca/ee/ca/) and select "Manual User Dual-Use Certificate Enrollment" 2. Fill out the form and submit request 3. Go to Agent interface (typically https://:9443/ca/agent/ca/) and approve submitted request 4. Return to EE interface, select "Retrieval" tab and "Check Request Status". 5. Type in request number and press submit. 6. Click on issued certificate serial number. 7. Go to the end of page displaying certificate and press "Import Your Certificate" 8. Start pkiconsole (typically by running "pkiconsole https://`hostname`:9445/ca") 9. Select "Users and Groups" and select your admin entry. 10. Press "Certificates" button then "Import" and paste in your new base64 encoded certificate, then OK and "Done" 11. Clear SSL cache in the browser or restart your browser. 12. You should now be able to use your new certificate to access Agent interface Thanks, Andrew ________________________________________ From: pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] On Behalf Of Andrew Wnuk [awnuk at redhat.com] Sent: Thursday, October 03, 2013 6:05 PM To: pki-users at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca Hi Richard, You can renew certificate using: https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/renewing-certificates.html and then add new certificate to CA administrator entry using console. Best, Andrew On 10/03/2013 08:49 AM, Richard Thomas wrote: Hi all, I hope someone would be able to help me with this. I have taken over a Dog Tag system and I have little knowledge of it. I need to renew the "CA Administrator of Instance pki-ca" certificate, as it is running out in a few weeks. Would someone be able to point me in the direction of any documentation on how to do this or let me know how to do it. I would massively appreciate any guidance on this. Thanks in advance, Richard. The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [cid:image001.jpg at 01CECA7C.5AE95680] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [cid:image001.jpg at 01CECA7C.5AE95680] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 895 bytes Desc: image001.jpg URL: From awnuk at redhat.com Thu Oct 17 00:42:48 2013 From: awnuk at redhat.com (Andrew Wnuk) Date: Wed, 16 Oct 2013 17:42:48 -0700 Subject: [Pki-users] CA Administrator of Instance pki-ca In-Reply-To: <574459158D85E14CBBA091C8AD9B44E27B3665AEF3@ms03.GS.TLG.PRIVATE> References: <574459158D85E14CBBA091C8AD9B44E27B34EFEECF@ms03.GS.TLG.PRIVATE>, <524DA3EE.3080605@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B34EFDF65@ms03.GS.TLG.PRIVATE> <52544E1C.2010308@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AEA5@ms03.GS.TLG.PRIVATE> <52588E08.2010803@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AED7@ms03.GS.TLG.PRIVATE> <525D7038.4010206@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AEF3@ms03.GS.TLG.PRIVATE> Message-ID: <525F3288.8030000@redhat.com> On 10/16/2013 06:31 AM, Richard Thomas wrote: > > Hi Andrew, > > Thanks for your email, I got past that issue once I made some edits to > some .cfg files in /var/lib/pki-ca/profiles/ca/ (shown at the bottom > of this email). > > That meant I could get as far as "Install a certificate" and I got a > choice of the following when doing so: > > o) Certificate Manager CA Signing Certificate(s) > > o) OCSP Signing Certificate(s) > > o) SSL Server Certificate(s) > > o) Cross-signed Certificate(s) > > o) Other Certificate(s) > > Please could you let me know which of the above option I should select. > The first 3 options should work for your CA but you are missing entries for subsytem and audit certificates. You may import certificates manually using certutil. For this you need to 1. stop your CA 2. change directory to /var/lib/pki-ca/alias/ 3. check current content of CA's NSS-DB by running certutil -d . -L 4. import certificates using identical trust bits and nicknames certutil -d . -A -n '' -t '' -a -i '' 5. start your CA If you need to alter nicknames, please reflect this in CS.cfg file. > Thank you. > > Richard. > > Here's what I did to be able to "Renew certificate to be manually > approved by agents". > > Edit file /var/lib/pki-ca/profiles/ca/caServerCert.cfg > > Change: > > visible=false > > enable=false > > To: > > visible=true > > enable=true > > Edit file /var/lib/pki-ca/profiles/ca/caOCSPCert.cfg > > Change: > > visible=false > > enable=false > > To: > > visible=true > > enable=true > > Edit file /var/lib/pki-ca/profiles/ca/caSignedLogCert.cfg > > Change: > > visible=false > > enable=false > > To: > > visible=true > > enable=true > visible=true makes enrollment visible on enrollment list page enable=true enables specific enrollment profile Both changes are fine. > service pki-cad restart > > *From:*Andrew Wnuk [mailto:awnuk at redhat.com] > *Sent:* 15 October 2013 17:41 > *To:* Richard Thomas > *Cc:* pki-users at redhat.com > *Subject:* Re: [Pki-users] CA Administrator of Instance pki-ca > > On 10/15/2013 02:35 AM, Richard Thomas wrote: > > Hi Andrew, > > Thanks again for getting back to me. > > Unfortunately, I didn't get very far. > > I've shown below what I have done and what it resulted in: > > o) Go to the :9443/ca/agent/ca URL and list the > certificates stored in Dogtag. > > o) Make a note of of the Certificate Serial Numbers of the > following certificates and change the hex value into decimal: > > CN=OCSP Signing Certificate E.G. 2 > > CN= E.G. 3 > > CN=CA Subsystem Certificate E.G. 4 > > CN=CA Audit Signing Certificate E.G. 5 > > CN= E.G. 268369921 > > o) Go to the :9444/ca/ee/ca URL > > o) Click on "Renewal: Renew certificate to be manually approved by > agents" > > o) Submit each of the Certificate Serial Numbers noted above and > make a note of the request ID > > For each Certificate Serial Number listed above that I submit, I > get the following: > > Sorry, your request is not submitted. The reason is "Profile > caServerCert Not Found". > > > > Check if caServerCert.cfg is listed under /var/lib/pki-ca/profiles/ca > and then check if /var/lib/pki-ca/conf/CS.cfg includes > > profile.list= . . . ,caServerCert, . . . > . . . > profile.caServerCert.class_id=caEnrollImpl > profile.caServerCert.config=/var/lib/pki-ca/profiles/ca/caServerCert.cfg > . . . > > > > Please could you help me further. > > Many thanks. > > Richard. > > *From:*Andrew Wnuk [mailto:awnuk at redhat.com] > *Sent:* 12 October 2013 00:47 > *To:* Richard Thomas > *Cc:* pki-users at redhat.com > *Subject:* Re: [Pki-users] CA Administrator of Instance pki-ca > > On 10/11/2013 07:04 AM, Richard Thomas wrote: > > Hi Andrew, > > Thanks for those tips, I had some success, then difficulty and > then success. > > Below is what I did, with some of my comments inline. > > Before I get to that though, there are some other certificates > that are due to run out soon, but I think they should be easier to > renew. > > The Common Name of those other certificates are: > > o) CN=OCSP Signing Certificate > > o) CN= > > o) CN=CA Subsystem Certificate > > o) CN=CA Audit Signing Certificate > > > As I noticed below, that your server provides option to "Renew > certificate to be manually approved by agents". > You should used this option for all your renewals. > > Then start pkiconsole go to "System Keys and Certificates", select > "Local Certificates", click on "Add/Renew", "Next" and "Install a > certificate" > > > > Please could you help me and let me know what steps I should take for > renewing these too. > > Thank you. > > Anyway, back to what I did to get the admin certificate updated. > > Your steps are still numbered, the ones that I did around them are > identified with o) > > Here goes: > > o) Edit /var/lib/pki-ca/profiles/ca/caUserCert.cfg > > Change: > > visible=false > > enable=false > > To: > > visible=true > > enable=true > > o) Restart service "pki-cad" > > 1. Go to EE interface (typically > https://:9444/ca/ee/ca/) and select "Manual User Dual-Use > Certificate Enrollment" > > 2. Fill out the form and submit request > > 3. Go to Agent interface (typically > https://:9443/ca/agent/ca/) and approve submitted request > > 4. Return to EE interface, select "Retrieval" tab and "Check Request > Status". > > 5. Type in request number and press submit. > > 6. Click on issued certificate serial number. > > >I did "List Certificates", went to the last page and found the certificate that way > > 7. Go to the end of page displaying certificate and press > "Import Your Certificate" > > >I got "The server returned an invalid client certificate. Error 207 > (net::ERR_CERT_INVALID)" > > > This probably means that browser which generated certificate request > (and the key) is not the same browser used to import certificate. > > > > > So having got stuck at this point, I figured I could use what I had done before and > then use your pkiconsole instructions. > > > The below is end-to-end from what I started off on my own and then across to the > second half of your instructions. > > o) Go to the :9444/ca/ee/ca URL > > o) Click on "Renewal: Renew certificate to be manually approved by > agents" (make a note of the number) > > o) Go to the :9443/ca/agent/ca URL to approve my request. (Use > the number above) > > o) Go to the :9444/ca/ee/ca URL to retrieve the certificate. > (Use the number above) and click on the Issued certificate > > o) Extract the Base 64 encoded part of the certificate and save as > .pem > > o) Transfer .p12 and name>.pem to a machine with openssl installed on it > > o) On a machine with openssl installed on it, submit following command: > > $openssl pkcs12 -in .p12 -out certificate bundle name>.pem -nodes > > o) Copy .pem to name>.pem > > o) Update .pem by replacing the relevant > part of it with the contents of .pem > > o) Cut the key part of .pem and create > .key from it > > o) Submit following command: > > $openssl pkcs12 -export -in .pem -inkey > .key -out .p12 > > o) Transfer .p12 to the machine with the > web browser that you want to access Dog Tag from. > > o) Import .p12 into the machine. > > 8. Start pkiconsole (typically by running "pkiconsole > https://`hostname`:9445/ca") > > 9. Select "Users and Groups" and select your admin entry. > > 10. Press "Certificates" button then "Import" and paste in > the contents of .pem, then OK and "Done" > > 11. Clear SSL cache in the browser or restart your browser. > > 12. You should now be able to use your new certificate to > access Agent interface > > >YES -- I can now access the agent interface using the new certificate J > > *From:*Andrew Wnuk [mailto:awnuk at redhat.com] > *Sent:* 08 October 2013 19:26 > *To:* Richard Thomas > *Cc:* pki-users-bounces at redhat.com > *Subject:* Re: [Pki-users] CA Administrator of Instance pki-ca > > On 10/07/2013 11:41 AM, Richard Thomas wrote: > > Hi Andrew, > > > > Thanks very much for sending this to me. > > > > The first thing I'd like to point out is that I'm using the pre-Red Hat enterprise variant of DogTag (dogtag-pki-1.3.0-2.el5) > > > > I have been trying to adapt the instructions as best I can and have so nearly got there, but not quite.. > > > > I have been referring to chapter 4.8.2 of that article by going to the :9444/ca/ee/ca URL and the only 2 Certificate Profiles I have to choose from are: > > o) Renewal: Renew certificate to be manually approved by agents > > o) Cisco VPN Client Enrolment > > > > The second option is for end users of our Cisco VPN to generate new certificates with, so I don't do anything with that. > > > > The first option looked promising, as it asked for a certificate number, so I used the :9443/ca/agent/ca URL to find the certificate number of the current "CA Administrator of Instance pki-ca" certificate, make a note of it and enter it into the certificate renewal page. > > > > I then use the :9443/ca/agent/ca URL to approve my request. > > > > Back to the :9444/ca/ee/ca URL to retrieve the certificate. > > > > I then updated the .p12 (.pfx) certificate with the one that appeared from the step above, with quite a bit of open_ssl commands, but I am confident that my new .p12 has everything in it as before (including the private key), with the exception of the "CA Administrator of Instance pki-ca" certificate being my updated one instead of the current one. > > > > I manage to import it into by machine's browser and when I navigate to :9443/ca/agent/ca, the new certificate comes up as an option to present to Dog Tag, so things are looking good at this stage and I select it. > > > > After that is where the first thing looks different, but I wasn't too worried about. I get a message saying "Request For Permission to Use a Key", so I grant permission. > > > > Then things don't look go at all, as once I'm past that, all the pages say "Invalid Credential". > > > > I have probably gone about things in a way that's more complicated than it should be and I guess it's because I'm using an earlier version of Dog Tag. > > > > Do you have any ideas where I have gone wrong with this please. > > > > Thank you very much. > > > > Richard. > > > > > Unfortunately your version is old enough to miss new renewal profiles, > which would make your task easier. > > Here is a simple way to renew your CA administrator certificate: > > 1. Go to EE interface (typically https://:9444/ca/ee/ca/) > and select "Manual User Dual-Use Certificate Enrollment" > 2. Fill out the form and submit request > 3. Go to Agent interface (typically > https://:9443/ca/agent/ca/) and approve submitted request > 4. Return to EE interface, select "Retrieval" tab and "Check Request > Status". > 5. Type in request number and press submit. > 6. Click on issued certificate serial number. > 7. Go to the end of page displaying certificate and press "Import > Your Certificate" > 8. Start pkiconsole (typically by running "pkiconsole > https://`hostname`:9445/ca") > 9. Select "Users and Groups" and select your admin entry. > 10. Press "Certificates" button then "Import" and paste in your new > base64 encoded certificate, then OK and "Done" > 11. Clear SSL cache in the browser or restart your browser. > 12. You should now be able to use your new certificate to access Agent > interface > > Thanks, > Andrew > > > > > > > ________________________________________ > From:pki-users-bounces at redhat.com [pki-users-bounces at redhat.com ] On Behalf Of Andrew Wnuk [awnuk at redhat.com ] > Sent: Thursday, October 03, 2013 6:05 PM > To:pki-users at redhat.com > Subject: Re: [Pki-users] CA Administrator of Instance pki-ca > > Hi Richard, > > You can renew certificate using:https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/renewing-certificates.html > and then add new certificate to CA administrator entry using console. > > Best, > Andrew > > On 10/03/2013 08:49 AM, Richard Thomas wrote: > Hi all, > > I hope someone would be able to help me with this. > > I have taken over a Dog Tag system and I have little knowledge of it. > > I need to renew the "CA Administrator of Instance pki-ca" certificate, as it is running out in a few weeks. > > Would someone be able to point me in the direction of any documentation on how to do this or let me know how to do it. > > I would massively appreciate any guidance on this. > > Thanks in advance, > > Richard. > > The world's first PCI accreditation for a Point to Point Encryption application. Find out more... > The Logic Group > Enterprises Limited > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom phone > fax > email > web +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com Registered in England > Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 > > The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. > > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > > > *The world's first PCI accreditation for a Point to Point Encryption > application.**Find out more... > ** > * > > The Logic Group > Enterprises Limited > > > > > > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom > > > > > > phone > fax > email > web > > > > +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com > > > > > > Registered in England > Number 2609323 > > > > > > http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business > Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered > No. 2609323 > > The information in this email and any attachments are confidential and > may be legally privileged and protected by law. It is for the intended > recipient only. If you are not the intended recipient you may not use, > disclose, copy, distribute, print or rely on the content of this email > or its attachments. If this email has been received by you in error > please advise the sender and delete the email from your system. > > *The world's first PCI accreditation for a Point to Point Encryption > application.**Find out more... > ** > * > > The Logic Group > Enterprises Limited > > > > > > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom > > > > > > phone > fax > email > web > > > > +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com > > > > > > Registered in England > Number 2609323 > > > > > > http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business > Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered > No. 2609323 > > The information in this email and any attachments are confidential and > may be legally privileged and protected by law. It is for the intended > recipient only. If you are not the intended recipient you may not use, > disclose, copy, distribute, print or rely on the content of this email > or its attachments. If this email has been received by you in error > please advise the sender and delete the email from your system. > > *The world's first PCI accreditation for a Point to Point Encryption > application.**Find out more... > > * > > The Logic Group > Enterprises Limited > > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom phone > fax > email > web +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com Registered in England > Number 2609323 > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business > Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered > No. 2609323 > > The information in this email and any attachments are confidential and > may be legally privileged and protected by law. It is for the intended > recipient only. If you are not the intended recipient you may not use, > disclose, copy, distribute, print or rely on the content of this email > or its attachments. If this email has been received by you in error > please advise the sender and delete the email from your system. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 895 bytes Desc: not available URL: From Richard.Thomas at the-logic-group.com Thu Oct 17 15:36:27 2013 From: Richard.Thomas at the-logic-group.com (Richard Thomas) Date: Thu, 17 Oct 2013 16:36:27 +0100 Subject: [Pki-users] CA Administrator of Instance pki-ca In-Reply-To: <525F3288.8030000@redhat.com> References: <574459158D85E14CBBA091C8AD9B44E27B34EFEECF@ms03.GS.TLG.PRIVATE>, <524DA3EE.3080605@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B34EFDF65@ms03.GS.TLG.PRIVATE> <52544E1C.2010308@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AEA5@ms03.GS.TLG.PRIVATE> <52588E08.2010803@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AED7@ms03.GS.TLG.PRIVATE> <525D7038.4010206@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AEF3@ms03.GS.TLG.PRIVATE> <525F3288.8030000@redhat.com> Message-ID: <574459158D85E14CBBA091C8AD9B44E27B3665AF10@ms03.GS.TLG.PRIVATE> Hi Andrew, Thanks for that, I've been using certutil on a set of files that I have copied from /var/lib/pki-ca/alias/ to /tmp/alias/ so that I can practice on non live certificate database files. Here is what I have done whilst in the /tmp/alias/ directory: $certutil -d . -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,u $certutil -d . -A -n 'ocspSigningCert cert-pki-ca' -t 'u,u,u' -a -i '/tmp/OCSP Signing Certificate-2013-2014.pem' $certutil -d . -A -n 'subsystemCert cert-pki-ca' -t 'u,u,u' -a -i '/tmp/CA Subsystem Certificate-2013-2014.pem' $certutil -d . -A -n 'caSigningCert cert-pki-ca' -t 'CTu,Cu,Cu' -a -i '/tmp/OCSP Signing Certificate-2013-2014.pem' $certutil -d . -A -n 'Server-Cert cert-pki-ca' -t 'u,u,u' -a -i '/tmp/-2013-2014.pem' $certutil -d . -A -n 'auditSigningCert cert-pki-ca' -t 'u,u,u' -a -i '/tmp/CA Audit Signing Certificate-2013-2014.pem' $certutil -d . -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u ocspSigningCert cert-pki-ca CTu,Cu,Cu caSigningCert cert-pki-ca CTu,Cu,Cu Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,u Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,u I have a few queries about what I have done.... 1) The old and new certificates are in the database store, so how does DogTag know when to use the old and new certificates? E.G. Would I also have to update each ca..cert= parameter of /etc/pki-ca/CS.cfg with the new b64-encoded certificate? E.G. ca.audit_signing.cert=, ca.ocsp_signing.cert= etc. 2) I notice the following differences between original and new CA Audit Signing Certificates (may be on the others, but haven't looked yet). Is this anything to worry about? Original: Identifier: Authority Key Identifier - 2.5.29.35 Critical: no Key Identifier: Identifier: Key Usage: - 2.5.29.15 Critical: yes Key Usage: Digital Signature Non Repudiation Identifier: Authority Info Access: - 1.3.6.1.5.5.7.1.1 Critical: no Access Description: Method #0: ocsp Location #0: URIName: http://:9180/ca/ocsp Identifier: Extended Key Usage: - 2.5.29.37 Critical: no Extended Key Usage: 1.3.6.1.5.5.7.3.4 New cert that I generated: Extensions: Identifier: Authority Key Identifier - 2.5.29.35 Critical: no Key Identifier: 77:2E:A7:DA:1D:1C:AF:3A:2A:5C:09:02:80:B8:DD:31: 28:05:51:9A Identifier: Subject Key Identifier - 2.5.29.14 Critical: no Key Identifier: B9:B9:F0:09:0C:A2:F3:E4:A2:D3:F6:B9:63:6B:EA:2C: 96:52:22:55 Identifier: Key Usage: - 2.5.29.15 Critical: yes Key Usage: Digital Signature Non Repudiation Thanks again, Richard Thomas Senior Network Engineer direct +44 (0)1252 644 265 switchboard +44 (0)1252 776755 email richard.thomas at the-logic-group.com From: Andrew Wnuk [mailto:awnuk at redhat.com] Sent: 17 October 2013 01:43 To: Richard Thomas Cc: pki-users at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca On 10/16/2013 06:31 AM, Richard Thomas wrote: Hi Andrew, Thanks for your email, I got past that issue once I made some edits to some .cfg files in /var/lib/pki-ca/profiles/ca/ (shown at the bottom of this email). That meant I could get as far as "Install a certificate" and I got a choice of the following when doing so: o) Certificate Manager CA Signing Certificate(s) o) OCSP Signing Certificate(s) o) SSL Server Certificate(s) o) Cross-signed Certificate(s) o) Other Certificate(s) Please could you let me know which of the above option I should select. The first 3 options should work for your CA but you are missing entries for subsytem and audit certificates. You may import certificates manually using certutil. For this you need to 1. stop your CA 2. change directory to /var/lib/pki-ca/alias/ 3. check current content of CA's NSS-DB by running 4. certutil -d . -L 1. import certificates using identical trust bits and nicknames certutil -d . -A -n '' -t '' -a -i '' 2. start your CA If you need to alter nicknames, please reflect this in CS.cfg file. Thank you. Richard. Here's what I did to be able to "Renew certificate to be manually approved by agents". Edit file /var/lib/pki-ca/profiles/ca/caServerCert.cfg Change: visible=false enable=false To: visible=true enable=true Edit file /var/lib/pki-ca/profiles/ca/caOCSPCert.cfg Change: visible=false enable=false To: visible=true enable=true Edit file /var/lib/pki-ca/profiles/ca/caSignedLogCert.cfg Change: visible=false enable=false To: visible=true enable=true visible=true makes enrollment visible on enrollment list page enable=true enables specific enrollment profile Both changes are fine. service pki-cad restart From: Andrew Wnuk [mailto:awnuk at redhat.com] Sent: 15 October 2013 17:41 To: Richard Thomas Cc: pki-users at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca On 10/15/2013 02:35 AM, Richard Thomas wrote: Hi Andrew, Thanks again for getting back to me. Unfortunately, I didn't get very far. I've shown below what I have done and what it resulted in: o) Go to the :9443/ca/agent/ca URL and list the certificates stored in Dogtag. o) Make a note of of the Certificate Serial Numbers of the following certificates and change the hex value into decimal: CN=OCSP Signing Certificate E.G. 2 CN= E.G. 3 CN=CA Subsystem Certificate E.G. 4 CN=CA Audit Signing Certificate E.G. 5 CN= E.G. 268369921 o) Go to the :9444/ca/ee/ca URL o) Click on "Renewal: Renew certificate to be manually approved by agents" o) Submit each of the Certificate Serial Numbers noted above and make a note of the request ID For each Certificate Serial Number listed above that I submit, I get the following: Sorry, your request is not submitted. The reason is "Profile caServerCert Not Found". Check if caServerCert.cfg is listed under /var/lib/pki-ca/profiles/ca and then check if /var/lib/pki-ca/conf/CS.cfg includes profile.list= . . . ,caServerCert, . . . . . . profile.caServerCert.class_id=caEnrollImpl profile.caServerCert.config=/var/lib/pki-ca/profiles/ca/caServerCert.cfg . . . Please could you help me further. Many thanks. Richard. From: Andrew Wnuk [mailto:awnuk at redhat.com] Sent: 12 October 2013 00:47 To: Richard Thomas Cc: pki-users at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca On 10/11/2013 07:04 AM, Richard Thomas wrote: Hi Andrew, Thanks for those tips, I had some success, then difficulty and then success. Below is what I did, with some of my comments inline. Before I get to that though, there are some other certificates that are due to run out soon, but I think they should be easier to renew. The Common Name of those other certificates are: o) CN=OCSP Signing Certificate o) CN= o) CN=CA Subsystem Certificate o) CN=CA Audit Signing Certificate As I noticed below, that your server provides option to "Renew certificate to be manually approved by agents". You should used this option for all your renewals. Then start pkiconsole go to "System Keys and Certificates", select "Local Certificates", click on "Add/Renew", "Next" and "Install a certificate" Please could you help me and let me know what steps I should take for renewing these too. Thank you. Anyway, back to what I did to get the admin certificate updated. Your steps are still numbered, the ones that I did around them are identified with o) Here goes: o) Edit /var/lib/pki-ca/profiles/ca/caUserCert.cfg Change: visible=false enable=false To: visible=true enable=true o) Restart service "pki-cad" 1. Go to EE interface (typically https://:9444/ca/ee/ca/) and select "Manual User Dual-Use Certificate Enrollment" 2. Fill out the form and submit request 3. Go to Agent interface (typically https://:9443/ca/agent/ca/) and approve submitted request 4. Return to EE interface, select "Retrieval" tab and "Check Request Status". 5. Type in request number and press submit. 6. Click on issued certificate serial number. >I did "List Certificates", went to the last page and found the certificate that way 7. Go to the end of page displaying certificate and press "Import Your Certificate" >I got "The server returned an invalid client certificate. Error 207 (net::ERR_CERT_INVALID)" This probably means that browser which generated certificate request (and the key) is not the same browser used to import certificate. > So having got stuck at this point, I figured I could use what I had done before and then use your pkiconsole instructions. > The below is end-to-end from what I started off on my own and then across to the second half of your instructions. o) Go to the :9444/ca/ee/ca URL o) Click on "Renewal: Renew certificate to be manually approved by agents" (make a note of the number) o) Go to the :9443/ca/agent/ca URL to approve my request. (Use the number above) o) Go to the :9444/ca/ee/ca URL to retrieve the certificate. (Use the number above) and click on the Issued certificate o) Extract the Base 64 encoded part of the certificate and save as .pem o) Transfer .p12 and .pem to a machine with openssl installed on it o) On a machine with openssl installed on it, submit following command: $openssl pkcs12 -in .p12 -out .pem -nodes o) Copy .pem to .pem o) Update .pem by replacing the relevant part of it with the contents of .pem o) Cut the key part of .pem and create .key from it o) Submit following command: $openssl pkcs12 -export -in .pem -inkey .key -out .p12 o) Transfer .p12 to the machine with the web browser that you want to access Dog Tag from. o) Import .p12 into the machine. 8. Start pkiconsole (typically by running "pkiconsole https://`hostname`:9445/ca") 9. Select "Users and Groups" and select your admin entry. 10. Press "Certificates" button then "Import" and paste in the contents of .pem, then OK and "Done" 11. Clear SSL cache in the browser or restart your browser. 12. You should now be able to use your new certificate to access Agent interface >YES - I can now access the agent interface using the new certificate J From: Andrew Wnuk [mailto:awnuk at redhat.com] Sent: 08 October 2013 19:26 To: Richard Thomas Cc: pki-users-bounces at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca On 10/07/2013 11:41 AM, Richard Thomas wrote: Hi Andrew, Thanks very much for sending this to me. The first thing I'd like to point out is that I'm using the pre-Red Hat enterprise variant of DogTag (dogtag-pki-1.3.0-2.el5) I have been trying to adapt the instructions as best I can and have so nearly got there, but not quite.. I have been referring to chapter 4.8.2 of that article by going to the :9444/ca/ee/ca URL and the only 2 Certificate Profiles I have to choose from are: o) Renewal: Renew certificate to be manually approved by agents o) Cisco VPN Client Enrolment The second option is for end users of our Cisco VPN to generate new certificates with, so I don't do anything with that. The first option looked promising, as it asked for a certificate number, so I used the :9443/ca/agent/ca URL to find the certificate number of the current "CA Administrator of Instance pki-ca" certificate, make a note of it and enter it into the certificate renewal page. I then use the :9443/ca/agent/ca URL to approve my request. Back to the :9444/ca/ee/ca URL to retrieve the certificate. I then updated the .p12 (.pfx) certificate with the one that appeared from the step above, with quite a bit of open_ssl commands, but I am confident that my new .p12 has everything in it as before (including the private key), with the exception of the "CA Administrator of Instance pki-ca" certificate being my updated one instead of the current one. I manage to import it into by machine's browser and when I navigate to :9443/ca/agent/ca, the new certificate comes up as an option to present to Dog Tag, so things are looking good at this stage and I select it. After that is where the first thing looks different, but I wasn't too worried about. I get a message saying "Request For Permission to Use a Key", so I grant permission. Then things don't look go at all, as once I'm past that, all the pages say "Invalid Credential". I have probably gone about things in a way that's more complicated than it should be and I guess it's because I'm using an earlier version of Dog Tag. Do you have any ideas where I have gone wrong with this please. Thank you very much. Richard. Unfortunately your version is old enough to miss new renewal profiles, which would make your task easier. Here is a simple way to renew your CA administrator certificate: 1. Go to EE interface (typically https://:9444/ca/ee/ca/) and select "Manual User Dual-Use Certificate Enrollment" 2. Fill out the form and submit request 3. Go to Agent interface (typically https://:9443/ca/agent/ca/) and approve submitted request 4. Return to EE interface, select "Retrieval" tab and "Check Request Status". 5. Type in request number and press submit. 6. Click on issued certificate serial number. 7. Go to the end of page displaying certificate and press "Import Your Certificate" 8. Start pkiconsole (typically by running "pkiconsole https://`hostname`:9445/ca") 9. Select "Users and Groups" and select your admin entry. 10. Press "Certificates" button then "Import" and paste in your new base64 encoded certificate, then OK and "Done" 11. Clear SSL cache in the browser or restart your browser. 12. You should now be able to use your new certificate to access Agent interface Thanks, Andrew ________________________________________ From: pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] On Behalf Of Andrew Wnuk [awnuk at redhat.com] Sent: Thursday, October 03, 2013 6:05 PM To: pki-users at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca Hi Richard, You can renew certificate using: https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/renewing-certificates.html and then add new certificate to CA administrator entry using console. Best, Andrew On 10/03/2013 08:49 AM, Richard Thomas wrote: Hi all, I hope someone would be able to help me with this. I have taken over a Dog Tag system and I have little knowledge of it. I need to renew the "CA Administrator of Instance pki-ca" certificate, as it is running out in a few weeks. Would someone be able to point me in the direction of any documentation on how to do this or let me know how to do it. I would massively appreciate any guidance on this. Thanks in advance, Richard. The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [cid:image001.jpg at 01CECB4C.A6C403E0] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [cid:image001.jpg at 01CECB4C.A6C403E0] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 895 bytes Desc: image001.jpg URL: From awnuk at redhat.com Thu Oct 17 16:54:52 2013 From: awnuk at redhat.com (Andrew Wnuk) Date: Thu, 17 Oct 2013 09:54:52 -0700 Subject: [Pki-users] CA Administrator of Instance pki-ca In-Reply-To: <525F3288.8030000@redhat.com> References: <574459158D85E14CBBA091C8AD9B44E27B34EFEECF@ms03.GS.TLG.PRIVATE>, <524DA3EE.3080605@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B34EFDF65@ms03.GS.TLG.PRIVATE> <52544E1C.2010308@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AEA5@ms03.GS.TLG.PRIVATE> <52588E08.2010803@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AED7@ms03.GS.TLG.PRIVATE> <525D7038.4010206@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AEF3@ms03.GS.TLG.PRIVATE> <525F3288.8030000@redhat.com> Message-ID: <5260165C.3050506@redhat.com> On 10/16/2013 05:42 PM, Andrew Wnuk wrote: > On 10/16/2013 06:31 AM, Richard Thomas wrote: >> >> Hi Andrew, >> >> Thanks for your email, I got past that issue once I made some edits >> to some .cfg files in /var/lib/pki-ca/profiles/ca/ (shown at the >> bottom of this email). >> >> That meant I could get as far as "Install a certificate" and I got a >> choice of the following when doing so: >> >> o) Certificate Manager CA Signing Certificate(s) >> >> o) OCSP Signing Certificate(s) >> >> o) SSL Server Certificate(s) >> >> o) Cross-signed Certificate(s) >> >> o) Other Certificate(s) >> >> Please could you let me know which of the above option I should select. >> > > The first 3 options should work for your CA but you are missing > entries for subsytem and audit certificates. > > You may import certificates manually using certutil. > For this you need to > > 1. stop your CA > 2. change directory to /var/lib/pki-ca/alias/ > 3. > check current content of CA's NSS-DB by running > certutil -d . -L > 4. import certificates using identical trust bits and nicknames > certutil -d . -A -n '' -t '' -a -i ' including b64-encoded certificate>' > 5. start your CA > > > If you need to alter nicknames, please reflect this in CS.cfg file. Marc pointed out to me that manual procedure is documented in https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/renewing-subsystem-certificates.html#renewing-certificates-using-certutil > >> Thank you. >> >> Richard. >> >> Here's what I did to be able to "Renew certificate to be manually >> approved by agents". >> >> Edit file /var/lib/pki-ca/profiles/ca/caServerCert.cfg >> >> Change: >> >> visible=false >> >> enable=false >> >> To: >> >> visible=true >> >> enable=true >> >> Edit file /var/lib/pki-ca/profiles/ca/caOCSPCert.cfg >> >> Change: >> >> visible=false >> >> enable=false >> >> To: >> >> visible=true >> >> enable=true >> >> Edit file /var/lib/pki-ca/profiles/ca/caSignedLogCert.cfg >> >> Change: >> >> visible=false >> >> enable=false >> >> To: >> >> visible=true >> >> enable=true >> > > visible=true makes enrollment visible on enrollment list page > enable=true enables specific enrollment profile > > Both changes are fine. > >> service pki-cad restart >> >> *From:*Andrew Wnuk [mailto:awnuk at redhat.com] >> *Sent:* 15 October 2013 17:41 >> *To:* Richard Thomas >> *Cc:* pki-users at redhat.com >> *Subject:* Re: [Pki-users] CA Administrator of Instance pki-ca >> >> On 10/15/2013 02:35 AM, Richard Thomas wrote: >> >> Hi Andrew, >> >> Thanks again for getting back to me. >> >> Unfortunately, I didn't get very far. >> >> I've shown below what I have done and what it resulted in: >> >> o) Go to the :9443/ca/agent/ca URL and list the >> certificates stored in Dogtag. >> >> o) Make a note of of the Certificate Serial Numbers of the >> following certificates and change the hex value into decimal: >> >> CN=OCSP Signing Certificate E.G. 2 >> >> CN= E.G. 3 >> >> CN=CA Subsystem Certificate E.G. 4 >> >> CN=CA Audit Signing Certificate E.G. 5 >> >> CN= E.G. 268369921 >> >> o) Go to the :9444/ca/ee/ca URL >> >> o) Click on "Renewal: Renew certificate to be manually approved >> by agents" >> >> o) Submit each of the Certificate Serial Numbers noted above and >> make a note of the request ID >> >> For each Certificate Serial Number listed above that I submit, I >> get the following: >> >> Sorry, your request is not submitted. The reason is "Profile >> caServerCert Not Found". >> >> >> >> Check if caServerCert.cfg is listed under /var/lib/pki-ca/profiles/ca >> and then check if /var/lib/pki-ca/conf/CS.cfg includes >> >> profile.list= . . . ,caServerCert, . . . >> . . . >> profile.caServerCert.class_id=caEnrollImpl >> profile.caServerCert.config=/var/lib/pki-ca/profiles/ca/caServerCert.cfg >> . . . >> >> >> >> Please could you help me further. >> >> Many thanks. >> >> Richard. >> >> *From:*Andrew Wnuk [mailto:awnuk at redhat.com] >> *Sent:* 12 October 2013 00:47 >> *To:* Richard Thomas >> *Cc:* pki-users at redhat.com >> *Subject:* Re: [Pki-users] CA Administrator of Instance pki-ca >> >> On 10/11/2013 07:04 AM, Richard Thomas wrote: >> >> Hi Andrew, >> >> Thanks for those tips, I had some success, then difficulty and >> then success. >> >> Below is what I did, with some of my comments inline. >> >> Before I get to that though, there are some other certificates >> that are due to run out soon, but I think they should be easier >> to renew. >> >> The Common Name of those other certificates are: >> >> o) CN=OCSP Signing Certificate >> >> o) CN= >> >> o) CN=CA Subsystem Certificate >> >> o) CN=CA Audit Signing Certificate >> >> >> As I noticed below, that your server provides option to "Renew >> certificate to be manually approved by agents". >> You should used this option for all your renewals. >> >> Then start pkiconsole go to "System Keys and Certificates", select >> "Local Certificates", click on "Add/Renew", "Next" and "Install a >> certificate" >> >> >> >> Please could you help me and let me know what steps I should take for >> renewing these too. >> >> Thank you. >> >> Anyway, back to what I did to get the admin certificate updated. >> >> Your steps are still numbered, the ones that I did around them are >> identified with o) >> >> Here goes: >> >> o) Edit /var/lib/pki-ca/profiles/ca/caUserCert.cfg >> >> Change: >> >> visible=false >> >> enable=false >> >> To: >> >> visible=true >> >> enable=true >> >> o) Restart service "pki-cad" >> >> 1. Go to EE interface (typically >> https://:9444/ca/ee/ca/) and select "Manual User Dual-Use >> Certificate Enrollment" >> >> 2. Fill out the form and submit request >> >> 3. Go to Agent interface (typically >> https://:9443/ca/agent/ca/) and approve submitted request >> >> 4. Return to EE interface, select "Retrieval" tab and "Check Request >> Status". >> >> 5. Type in request number and press submit. >> >> 6. Click on issued certificate serial number. >> >> >I did "List Certificates", went to the last page and found the certificate that way >> >> 7. Go to the end of page displaying certificate and press >> "Import Your Certificate" >> >> >I got "The server returned an invalid client certificate. Error 207 >> (net::ERR_CERT_INVALID)" >> >> >> This probably means that browser which generated certificate request >> (and the key) is not the same browser used to import certificate. >> >> >> >> > So having got stuck at this point, I figured I could use what I had done >> before and then use your pkiconsole instructions. >> >> > The below is end-to-end from what I started off on my own and then across to the >> second half of your instructions. >> >> o) Go to the :9444/ca/ee/ca URL >> >> o) Click on "Renewal: Renew certificate to be manually approved by >> agents" (make a note of the number) >> >> o) Go to the :9443/ca/agent/ca URL to approve my request. >> (Use the number above) >> >> o) Go to the :9444/ca/ee/ca URL to retrieve the certificate. >> (Use the number above) and click on the Issued certificate >> >> o) Extract the Base 64 encoded part of the certificate and save as >> .pem >> >> o) Transfer .p12 and > name>.pem to a machine with openssl installed on it >> >> o) On a machine with openssl installed on it, submit following command: >> >> $openssl pkcs12 -in .p12 -out > certificate bundle name>.pem -nodes >> >> o) Copy .pem to > name>.pem >> >> o) Update .pem by replacing the relevant >> part of it with the contents of .pem >> >> o) Cut the key part of .pem and create >> .key from it >> >> o) Submit following command: >> >> $openssl pkcs12 -export -in .pem -inkey >> .key -out .p12 >> >> o) Transfer .p12 to the machine with the >> web browser that you want to access Dog Tag from. >> >> o) Import .p12 into the machine. >> >> 8. Start pkiconsole (typically by running "pkiconsole >> https://`hostname`:9445/ca") >> >> 9. Select "Users and Groups" and select your admin entry. >> >> 10. Press "Certificates" button then "Import" and paste in the >> contents of .pem, then OK and "Done" >> >> 11. Clear SSL cache in the browser or restart your browser. >> >> 12. You should now be able to use your new certificate to >> access Agent interface >> >> >YES -- I can now access the agent interface using the new certificate J >> >> *From:*Andrew Wnuk [mailto:awnuk at redhat.com] >> *Sent:* 08 October 2013 19:26 >> *To:* Richard Thomas >> *Cc:* pki-users-bounces at redhat.com >> *Subject:* Re: [Pki-users] CA Administrator of Instance pki-ca >> >> On 10/07/2013 11:41 AM, Richard Thomas wrote: >> >> Hi Andrew, >> >> >> >> Thanks very much for sending this to me. >> >> >> >> The first thing I'd like to point out is that I'm using the pre-Red Hat enterprise variant of DogTag (dogtag-pki-1.3.0-2.el5) >> >> >> >> I have been trying to adapt the instructions as best I can and have so nearly got there, but not quite.. >> >> >> >> I have been referring to chapter 4.8.2 of that article by going to the :9444/ca/ee/ca URL and the only 2 Certificate Profiles I have to choose from are: >> >> o) Renewal: Renew certificate to be manually approved by agents >> >> o) Cisco VPN Client Enrolment >> >> >> >> The second option is for end users of our Cisco VPN to generate new certificates with, so I don't do anything with that. >> >> >> >> The first option looked promising, as it asked for a certificate number, so I used the :9443/ca/agent/ca URL to find the certificate number of the current "CA Administrator of Instance pki-ca" certificate, make a note of it and enter it into the certificate renewal page. >> >> >> >> I then use the :9443/ca/agent/ca URL to approve my request. >> >> >> >> Back to the :9444/ca/ee/ca URL to retrieve the certificate. >> >> >> >> I then updated the .p12 (.pfx) certificate with the one that appeared from the step above, with quite a bit of open_ssl commands, but I am confident that my new .p12 has everything in it as before (including the private key), with the exception of the "CA Administrator of Instance pki-ca" certificate being my updated one instead of the current one. >> >> >> >> I manage to import it into by machine's browser and when I navigate to :9443/ca/agent/ca, the new certificate comes up as an option to present to Dog Tag, so things are looking good at this stage and I select it. >> >> >> >> After that is where the first thing looks different, but I wasn't too worried about. I get a message saying "Request For Permission to Use a Key", so I grant permission. >> >> >> >> Then things don't look go at all, as once I'm past that, all the pages say "Invalid Credential". >> >> >> >> I have probably gone about things in a way that's more complicated than it should be and I guess it's because I'm using an earlier version of Dog Tag. >> >> >> >> Do you have any ideas where I have gone wrong with this please. >> >> >> >> Thank you very much. >> >> >> >> Richard. >> >> >> >> >> Unfortunately your version is old enough to miss new renewal >> profiles, which would make your task easier. >> >> Here is a simple way to renew your CA administrator certificate: >> >> 1. Go to EE interface (typically https://:9444/ca/ee/ca/) >> and select "Manual User Dual-Use Certificate Enrollment" >> 2. Fill out the form and submit request >> 3. Go to Agent interface (typically >> https://:9443/ca/agent/ca/) and approve submitted request >> 4. Return to EE interface, select "Retrieval" tab and "Check Request >> Status". >> 5. Type in request number and press submit. >> 6. Click on issued certificate serial number. >> 7. Go to the end of page displaying certificate and press "Import >> Your Certificate" >> 8. Start pkiconsole (typically by running "pkiconsole >> https://`hostname`:9445/ca") >> 9. Select "Users and Groups" and select your admin entry. >> 10. Press "Certificates" button then "Import" and paste in your new >> base64 encoded certificate, then OK and "Done" >> 11. Clear SSL cache in the browser or restart your browser. >> 12. You should now be able to use your new certificate to access >> Agent interface >> >> Thanks, >> Andrew >> >> >> >> >> >> >> ________________________________________ >> From:pki-users-bounces at redhat.com [pki-users-bounces at redhat.com ] On Behalf Of Andrew Wnuk [awnuk at redhat.com ] >> Sent: Thursday, October 03, 2013 6:05 PM >> To:pki-users at redhat.com >> Subject: Re: [Pki-users] CA Administrator of Instance pki-ca >> >> Hi Richard, >> >> You can renew certificate using:https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/renewing-certificates.html >> and then add new certificate to CA administrator entry using console. >> >> Best, >> Andrew >> >> On 10/03/2013 08:49 AM, Richard Thomas wrote: >> Hi all, >> >> I hope someone would be able to help me with this. >> >> I have taken over a Dog Tag system and I have little knowledge of it. >> >> I need to renew the "CA Administrator of Instance pki-ca" certificate, as it is running out in a few weeks. >> >> Would someone be able to point me in the direction of any documentation on how to do this or let me know how to do it. >> >> I would massively appreciate any guidance on this. >> >> Thanks in advance, >> >> Richard. >> >> The world's first PCI accreditation for a Point to Point Encryption application. Find out more... >> The Logic Group >> Enterprises Limited >> Logic House >> Waterfront Business Park >> Fleet, Hampshire >> GU51 3SB >> United Kingdom phone >> fax >> email >> web +44 1252 776 700 >> +44 1252 776 738 >> info at the-logic-group.com >> www.the-logic-group.com Registered in England >> Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] >> >> >> >> The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, >> Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 >> >> The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. >> >> >> >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> *The world's first PCI accreditation for a Point to Point Encryption >> application.**Find out more... >> ** >> * >> >> The Logic Group >> Enterprises Limited >> >> >> >> >> >> Logic House >> Waterfront Business Park >> Fleet, Hampshire >> GU51 3SB >> United Kingdom >> >> >> >> >> >> phone >> fax >> email >> web >> >> >> >> +44 1252 776 700 >> +44 1252 776 738 >> info at the-logic-group.com >> www.the-logic-group.com >> >> >> >> >> >> Registered in England >> Number 2609323 >> >> >> >> >> >> http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg >> >> >> >> The Logic Group Enterprises Limited, Logic House, Waterfront Business >> Park, Fleet Road, Fleet, >> Hampshire, GU51 3SB, United Kingdom. Registered in England. >> Registered No. 2609323 >> >> The information in this email and any attachments are confidential >> and may be legally privileged and protected by law. It is for the >> intended recipient only. If you are not the intended recipient you >> may not use, disclose, copy, distribute, print or rely on the content >> of this email or its attachments. If this email has been received by >> you in error please advise the sender and delete the email from your >> system. >> >> *The world's first PCI accreditation for a Point to Point Encryption >> application.**Find out more... >> ** >> * >> >> The Logic Group >> Enterprises Limited >> >> >> >> >> >> Logic House >> Waterfront Business Park >> Fleet, Hampshire >> GU51 3SB >> United Kingdom >> >> >> >> >> >> phone >> fax >> email >> web >> >> >> >> +44 1252 776 700 >> +44 1252 776 738 >> info at the-logic-group.com >> www.the-logic-group.com >> >> >> >> >> >> Registered in England >> Number 2609323 >> >> >> >> >> >> http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg >> >> >> >> The Logic Group Enterprises Limited, Logic House, Waterfront Business >> Park, Fleet Road, Fleet, >> Hampshire, GU51 3SB, United Kingdom. Registered in England. >> Registered No. 2609323 >> >> The information in this email and any attachments are confidential >> and may be legally privileged and protected by law. It is for the >> intended recipient only. If you are not the intended recipient you >> may not use, disclose, copy, distribute, print or rely on the content >> of this email or its attachments. If this email has been received by >> you in error please advise the sender and delete the email from your >> system. >> >> *The world's first PCI accreditation for a Point to Point Encryption >> application.**Find out more... >> >> * >> >> The Logic Group >> Enterprises Limited >> >> Logic House >> Waterfront Business Park >> Fleet, Hampshire >> GU51 3SB >> United Kingdom phone >> fax >> email >> web +44 1252 776 700 >> +44 1252 776 738 >> info at the-logic-group.com >> www.the-logic-group.com Registered in England >> Number 2609323 >> >> >> >> The Logic Group Enterprises Limited, Logic House, Waterfront Business >> Park, Fleet Road, Fleet, >> Hampshire, GU51 3SB, United Kingdom. Registered in England. >> Registered No. 2609323 >> >> The information in this email and any attachments are confidential >> and may be legally privileged and protected by law. It is for the >> intended recipient only. If you are not the intended recipient you >> may not use, disclose, copy, distribute, print or rely on the content >> of this email or its attachments. If this email has been received by >> you in error please advise the sender and delete the email from your >> system. >> >> > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 895 bytes Desc: not available URL: From awnuk at redhat.com Fri Oct 18 17:27:27 2013 From: awnuk at redhat.com (Andrew Wnuk) Date: Fri, 18 Oct 2013 10:27:27 -0700 Subject: [Pki-users] CA Administrator of Instance pki-ca In-Reply-To: <574459158D85E14CBBA091C8AD9B44E27B3665AF10@ms03.GS.TLG.PRIVATE> References: <574459158D85E14CBBA091C8AD9B44E27B34EFEECF@ms03.GS.TLG.PRIVATE>, <524DA3EE.3080605@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B34EFDF65@ms03.GS.TLG.PRIVATE> <52544E1C.2010308@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AEA5@ms03.GS.TLG.PRIVATE> <52588E08.2010803@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AED7@ms03.GS.TLG.PRIVATE> <525D7038.4010206@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AEF3@ms03.GS.TLG.PRIVATE> <525F3288.8030000@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AF10@ms03.GS.TLG.PRIVATE> Message-ID: <52616F7F.8030908@redhat.com> On 10/17/2013 08:36 AM, Richard Thomas wrote: > > Hi Andrew, > > Thanks for that, I've been using certutil on a set of files that I > have copied from /var/lib/pki-ca/alias/ to /tmp/alias/ so that I can > practice on non live certificate database files. > > Here is what I have done whilst in the /tmp/alias/ directory: > > $certutil -d . -L > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > ocspSigningCert cert-pki-ca u,u,u > > subsystemCert cert-pki-ca u,u,u > > caSigningCert cert-pki-ca CTu,Cu,Cu > > Server-Cert cert-pki-ca u,u,u > > auditSigningCert cert-pki-ca u,u,u > > $certutil -d . -A -n 'ocspSigningCert cert-pki-ca' -t 'u,u,u' -a -i > '/tmp/OCSP Signing Certificate-2013-2014.pem' > > $certutil -d . -A -n 'subsystemCert cert-pki-ca' -t 'u,u,u' -a -i > '/tmp/CA Subsystem Certificate-2013-2014.pem' > > $certutil -d . -A -n 'caSigningCert cert-pki-ca' -t 'CTu,Cu,Cu' -a -i > '/tmp/OCSP Signing Certificate-2013-2014.pem' > > $certutil -d . -A -n 'Server-Cert cert-pki-ca' -t 'u,u,u' -a -i > '/tmp/-2013-2014.pem' > > $certutil -d . -A -n 'auditSigningCert cert-pki-ca' -t 'u,u,u' -a -i > '/tmp/CA Audit Signing Certificate-2013-2014.pem' > > $certutil -d . -L > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > ocspSigningCert cert-pki-ca u,u,u > > subsystemCert cert-pki-ca u,u,u > > subsystemCert cert-pki-ca u,u,u > > ocspSigningCert cert-pki-ca CTu,Cu,Cu > OCSP trust bits should stay as "u,u,u" > > caSigningCert cert-pki-ca CTu,Cu,Cu > > Server-Cert cert-pki-ca u,u,u > > auditSigningCert cert-pki-ca u,u,u > > Server-Cert cert-pki-ca u,u,u > > auditSigningCert cert-pki-ca u,u,u > > I have a few queries about what I have done.... > > 1)The old and new certificates are in the database store, so how does > DogTag know when to use the old and new certificates? > Dogtag requests certificates by nickname. NSS library is providing the best choice based on nickname provided by Dogtag. To avoid any potential problem, you may choose to remove old certificates before importing the new certificates as suggested in the following documentation: https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/renewing-subsystem-certificates.html#renewing-certificates-using-certutil > E.G. Would I also have to update each ca..cert= parameter > of /etc/pki-ca/CS.cfg with the new b64-encoded certificate? E.G. > ca.audit_signing.cert=, ca.ocsp_signing.cert= etc. > > 2)I notice the following differences between original and new CA Audit > Signing Certificates (may be on the others, but haven't looked yet). > Is this anything to worry about? > > Original: > > Identifier: Authority Key Identifier - 2.5.29.35 > > Critical: no > > Key Identifier: > > > > Identifier: Key Usage: - 2.5.29.15 > > Critical: yes > > Key Usage: > > Digital Signature > > Non Repudiation > > Identifier: Authority Info Access: - 1.3.6.1.5.5.7.1.1 > > Critical: no > > Access Description: > > Method #0: ocsp > > Location #0: URIName: http://:9180/ca/ocsp > > Identifier: Extended Key Usage: - 2.5.29.37 > > Critical: no > > Extended Key Usage: > > 1.3.6.1.5.5.7.3.4 > > New cert that I generated: > > Extensions: > > Identifier: Authority Key Identifier - 2.5.29.35 > > Critical: no > > Key Identifier: > > 77:2E:A7:DA:1D:1C:AF:3A:2A:5C:09:02:80:B8:DD:31: > > 28:05:51:9A > > Identifier: Subject Key Identifier - 2.5.29.14 > > Critical: no > > Key Identifier: > > B9:B9:F0:09:0C:A2:F3:E4:A2:D3:F6:B9:63:6B:EA:2C: > > 96:52:22:55 > > Identifier: Key Usage: - 2.5.29.15 > > Critical: yes > > Key Usage: > > Digital Signature > > Non Repudiation > Key usage is the same so it should work as this is just auditing certificate. > Thanks again, > > ** > > *Richard Thomas* > Senior Network Engineer > > direct+44 (0)1252 644 265 > switchboard+44 (0)1252 776755 > email richard.thomas at the-logic-group.com > > > *From:*Andrew Wnuk [mailto:awnuk at redhat.com] > *Sent:* 17 October 2013 01:43 > *To:* Richard Thomas > *Cc:* pki-users at redhat.com > *Subject:* Re: [Pki-users] CA Administrator of Instance pki-ca > > On 10/16/2013 06:31 AM, Richard Thomas wrote: > > Hi Andrew, > > Thanks for your email, I got past that issue once I made some > edits to some .cfg files in /var/lib/pki-ca/profiles/ca/ (shown at > the bottom of this email). > > That meant I could get as far as "Install a certificate" and I got > a choice of the following when doing so: > > o) Certificate Manager CA Signing Certificate(s) > > o) OCSP Signing Certificate(s) > > o) SSL Server Certificate(s) > > o) Cross-signed Certificate(s) > > o) Other Certificate(s) > > Please could you let me know which of the above option I should > select. > > > The first 3 options should work for your CA but you are missing > entries for subsytem and audit certificates. > > You may import certificates manually using certutil. > For this you need to > > 1. stop your CA > 2. change directory to /var/lib/pki-ca/alias/ > > 3. check current content of CA's NSS-DB by running > 4. certutil -d . -L > > 5. import certificates using identical trust bits and nicknames > certutil -d . -A -n '' -t '' -a -i ' including b64-encoded certificate>' > 6. start your CA > > > If you need to alter nicknames, please reflect this in CS.cfg file. > > > Thank you. > > Richard. > > Here's what I did to be able to "Renew certificate to be manually > approved by agents". > > Edit file /var/lib/pki-ca/profiles/ca/caServerCert.cfg > > Change: > > visible=false > > enable=false > > To: > > visible=true > > enable=true > > Edit file /var/lib/pki-ca/profiles/ca/caOCSPCert.cfg > > Change: > > visible=false > > enable=false > > To: > > visible=true > > enable=true > > Edit file /var/lib/pki-ca/profiles/ca/caSignedLogCert.cfg > > Change: > > visible=false > > enable=false > > To: > > visible=true > > enable=true > > > visible=true makes enrollment visible on enrollment list page > enable=true enables specific enrollment profile > > Both changes are fine. > > > service pki-cad restart > > *From:*Andrew Wnuk [mailto:awnuk at redhat.com] > *Sent:* 15 October 2013 17:41 > *To:* Richard Thomas > *Cc:* pki-users at redhat.com > *Subject:* Re: [Pki-users] CA Administrator of Instance pki-ca > > On 10/15/2013 02:35 AM, Richard Thomas wrote: > > Hi Andrew, > > Thanks again for getting back to me. > > Unfortunately, I didn't get very far. > > I've shown below what I have done and what it resulted in: > > o) Go to the :9443/ca/agent/ca URL and list the > certificates stored in Dogtag. > > o) Make a note of of the Certificate Serial Numbers of the > following certificates and change the hex value into decimal: > > CN=OCSP Signing Certificate E.G. 2 > > CN= E.G. 3 > > CN=CA Subsystem Certificate E.G. 4 > > CN=CA Audit Signing Certificate E.G. 5 > > CN= E.G. 268369921 > > o) Go to the :9444/ca/ee/ca URL > > o) Click on "Renewal: Renew certificate to be manually approved by > agents" > > o) Submit each of the Certificate Serial Numbers noted above and > make a note of the request ID > > For each Certificate Serial Number listed above that I submit, I > get the following: > > Sorry, your request is not submitted. The reason is "Profile > caServerCert Not Found". > > > > Check if caServerCert.cfg is listed under /var/lib/pki-ca/profiles/ca > and then check if /var/lib/pki-ca/conf/CS.cfg includes > > profile.list= . . . ,caServerCert, . . . > . . . > profile.caServerCert.class_id=caEnrollImpl > profile.caServerCert.config=/var/lib/pki-ca/profiles/ca/caServerCert.cfg > . . . > > > > > Please could you help me further. > > Many thanks. > > Richard. > > *From:*Andrew Wnuk [mailto:awnuk at redhat.com] > *Sent:* 12 October 2013 00:47 > *To:* Richard Thomas > *Cc:* pki-users at redhat.com > *Subject:* Re: [Pki-users] CA Administrator of Instance pki-ca > > On 10/11/2013 07:04 AM, Richard Thomas wrote: > > Hi Andrew, > > Thanks for those tips, I had some success, then difficulty and > then success. > > Below is what I did, with some of my comments inline. > > Before I get to that though, there are some other certificates > that are due to run out soon, but I think they should be easier to > renew. > > The Common Name of those other certificates are: > > o) CN=OCSP Signing Certificate > > o) CN= > > o) CN=CA Subsystem Certificate > > o) CN=CA Audit Signing Certificate > > > As I noticed below, that your server provides option to "Renew > certificate to be manually approved by agents". > You should used this option for all your renewals. > > Then start pkiconsole go to "System Keys and Certificates", select > "Local Certificates", click on "Add/Renew", "Next" and "Install a > certificate" > > > > > Please could you help me and let me know what steps I should take for > renewing these too. > > Thank you. > > Anyway, back to what I did to get the admin certificate updated. > > Your steps are still numbered, the ones that I did around them are > identified with o) > > Here goes: > > o) Edit /var/lib/pki-ca/profiles/ca/caUserCert.cfg > > Change: > > visible=false > > enable=false > > To: > > visible=true > > enable=true > > o) Restart service "pki-cad" > > 1. Go to EE interface (typically > https://:9444/ca/ee/ca/) and select "Manual User Dual-Use > Certificate Enrollment" > > 2. Fill out the form and submit request > > 3. Go to Agent interface (typically > https://:9443/ca/agent/ca/) and approve submitted request > > 4. Return to EE interface, select "Retrieval" tab and "Check Request > Status". > > 5. Type in request number and press submit. > > 6. Click on issued certificate serial number. > > >I did "List Certificates", went to the last page and found the certificate that way > > 7. Go to the end of page displaying certificate and press > "Import Your Certificate" > > >I got "The server returned an invalid client certificate. Error 207 > (net::ERR_CERT_INVALID)" > > > This probably means that browser which generated certificate request > (and the key) is not the same browser used to import certificate. > > > > > > So having got stuck at this point, I figured I could use what I had done before and > then use your pkiconsole instructions. > > > The below is end-to-end from what I started off on my own and then across to the > second half of your instructions. > > o) Go to the :9444/ca/ee/ca URL > > o) Click on "Renewal: Renew certificate to be manually approved by > agents" (make a note of the number) > > o) Go to the :9443/ca/agent/ca URL to approve my request. (Use > the number above) > > o) Go to the :9444/ca/ee/ca URL to retrieve the certificate. > (Use the number above) and click on the Issued certificate > > o) Extract the Base 64 encoded part of the certificate and save as > .pem > > o) Transfer .p12 and name>.pem to a machine with openssl installed on it > > o) On a machine with openssl installed on it, submit following command: > > $openssl pkcs12 -in .p12 -out certificate bundle name>.pem -nodes > > o) Copy .pem to name>.pem > > o) Update .pem by replacing the relevant > part of it with the contents of .pem > > o) Cut the key part of .pem and create > .key from it > > o) Submit following command: > > $openssl pkcs12 -export -in .pem -inkey > .key -out .p12 > > o) Transfer .p12 to the machine with the > web browser that you want to access Dog Tag from. > > o) Import .p12 into the machine. > > 8. Start pkiconsole (typically by running "pkiconsole > https://`hostname`:9445/ca") > > 9. Select "Users and Groups" and select your admin entry. > > 10. Press "Certificates" button then "Import" and paste in > the contents of .pem, then OK and "Done" > > 11. Clear SSL cache in the browser or restart your browser. > > 12. You should now be able to use your new certificate to > access Agent interface > > >YES -- I can now access the agent interface using the new certificate J > > *From:*Andrew Wnuk [mailto:awnuk at redhat.com] > *Sent:* 08 October 2013 19:26 > *To:* Richard Thomas > *Cc:* pki-users-bounces at redhat.com > *Subject:* Re: [Pki-users] CA Administrator of Instance pki-ca > > On 10/07/2013 11:41 AM, Richard Thomas wrote: > > Hi Andrew, > > > > Thanks very much for sending this to me. > > > > The first thing I'd like to point out is that I'm using the pre-Red Hat enterprise variant of DogTag (dogtag-pki-1.3.0-2.el5) > > > > I have been trying to adapt the instructions as best I can and have so nearly got there, but not quite.. > > > > I have been referring to chapter 4.8.2 of that article by going to the :9444/ca/ee/ca URL and the only 2 Certificate Profiles I have to choose from are: > > o) Renewal: Renew certificate to be manually approved by agents > > o) Cisco VPN Client Enrolment > > > > The second option is for end users of our Cisco VPN to generate new certificates with, so I don't do anything with that. > > > > The first option looked promising, as it asked for a certificate number, so I used the :9443/ca/agent/ca URL to find the certificate number of the current "CA Administrator of Instance pki-ca" certificate, make a note of it and enter it into the certificate renewal page. > > > > I then use the :9443/ca/agent/ca URL to approve my request. > > > > Back to the :9444/ca/ee/ca URL to retrieve the certificate. > > > > I then updated the .p12 (.pfx) certificate with the one that appeared from the step above, with quite a bit of open_ssl commands, but I am confident that my new .p12 has everything in it as before (including the private key), with the exception of the "CA Administrator of Instance pki-ca" certificate being my updated one instead of the current one. > > > > I manage to import it into by machine's browser and when I navigate to :9443/ca/agent/ca, the new certificate comes up as an option to present to Dog Tag, so things are looking good at this stage and I select it. > > > > After that is where the first thing looks different, but I wasn't too worried about. I get a message saying "Request For Permission to Use a Key", so I grant permission. > > > > Then things don't look go at all, as once I'm past that, all the pages say "Invalid Credential". > > > > I have probably gone about things in a way that's more complicated than it should be and I guess it's because I'm using an earlier version of Dog Tag. > > > > Do you have any ideas where I have gone wrong with this please. > > > > Thank you very much. > > > > Richard. > > > > > Unfortunately your version is old enough to miss new renewal profiles, > which would make your task easier. > > Here is a simple way to renew your CA administrator certificate: > > 1. Go to EE interface (typically https://:9444/ca/ee/ca/) > and select "Manual User Dual-Use Certificate Enrollment" > 2. Fill out the form and submit request > 3. Go to Agent interface (typically > https://:9443/ca/agent/ca/) and approve submitted request > 4. Return to EE interface, select "Retrieval" tab and "Check Request > Status". > 5. Type in request number and press submit. > 6. Click on issued certificate serial number. > 7. Go to the end of page displaying certificate and press "Import > Your Certificate" > 8. Start pkiconsole (typically by running "pkiconsole > https://`hostname`:9445/ca") > 9. Select "Users and Groups" and select your admin entry. > 10. Press "Certificates" button then "Import" and paste in your new > base64 encoded certificate, then OK and "Done" > 11. Clear SSL cache in the browser or restart your browser. > 12. You should now be able to use your new certificate to access Agent > interface > > Thanks, > Andrew > > > > > > > > ________________________________________ > From:pki-users-bounces at redhat.com [pki-users-bounces at redhat.com ] On Behalf Of Andrew Wnuk [awnuk at redhat.com ] > Sent: Thursday, October 03, 2013 6:05 PM > To:pki-users at redhat.com > Subject: Re: [Pki-users] CA Administrator of Instance pki-ca > > Hi Richard, > > You can renew certificate using:https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/renewing-certificates.html > and then add new certificate to CA administrator entry using console. > > Best, > Andrew > > On 10/03/2013 08:49 AM, Richard Thomas wrote: > Hi all, > > I hope someone would be able to help me with this. > > I have taken over a Dog Tag system and I have little knowledge of it. > > I need to renew the "CA Administrator of Instance pki-ca" certificate, as it is running out in a few weeks. > > Would someone be able to point me in the direction of any documentation on how to do this or let me know how to do it. > > I would massively appreciate any guidance on this. > > Thanks in advance, > > Richard. > > The world's first PCI accreditation for a Point to Point Encryption application. Find out more... > The Logic Group > Enterprises Limited > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom phone > fax > email > web +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com Registered in England > Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 > > The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. > > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > > > *The world's first PCI accreditation for a Point to Point Encryption > application.**Find out more... > ** > * > > The Logic Group > Enterprises Limited > > > > > > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom > > > > > > phone > fax > email > web > > > > +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com > > > > > > Registered in England > Number 2609323 > > > > > > http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business > Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered > No. 2609323 > > The information in this email and any attachments are confidential and > may be legally privileged and protected by law. It is for the intended > recipient only. If you are not the intended recipient you may not use, > disclose, copy, distribute, print or rely on the content of this email > or its attachments. If this email has been received by you in error > please advise the sender and delete the email from your system. > > *The world's first PCI accreditation for a Point to Point Encryption > application.**Find out more... > ** > * > > The Logic Group > Enterprises Limited > > > > > > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom > > > > > > phone > fax > email > web > > > > +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com > > > > > > Registered in England > Number 2609323 > > > > > > http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business > Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered > No. 2609323 > > The information in this email and any attachments are confidential and > may be legally privileged and protected by law. It is for the intended > recipient only. If you are not the intended recipient you may not use, > disclose, copy, distribute, print or rely on the content of this email > or its attachments. If this email has been received by you in error > please advise the sender and delete the email from your system. > > *The world's first PCI accreditation for a Point to Point Encryption > application.**Find out more... > ** > * > > The Logic Group > Enterprises Limited > > > > > > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom > > > > > > phone > fax > email > web > > > > +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com > > > > > > Registered in England > Number 2609323 > > > > > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business > Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered > No. 2609323 > > The information in this email and any attachments are confidential and > may be legally privileged and protected by law. It is for the intended > recipient only. If you are not the intended recipient you may not use, > disclose, copy, distribute, print or rely on the content of this email > or its attachments. If this email has been received by you in error > please advise the sender and delete the email from your system. > > *The world's first PCI accreditation for a Point to Point Encryption > application.**Find out more... > > * > > The Logic Group > Enterprises Limited > > Logic House > Waterfront Business Park > Fleet, Hampshire > GU51 3SB > United Kingdom phone > fax > email > web +44 1252 776 700 > +44 1252 776 738 > info at the-logic-group.com > www.the-logic-group.com Registered in England > Number 2609323 > > > > The Logic Group Enterprises Limited, Logic House, Waterfront Business > Park, Fleet Road, Fleet, > Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered > No. 2609323 > > The information in this email and any attachments are confidential and > may be legally privileged and protected by law. It is for the intended > recipient only. If you are not the intended recipient you may not use, > disclose, copy, distribute, print or rely on the content of this email > or its attachments. If this email has been received by you in error > please advise the sender and delete the email from your system. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 895 bytes Desc: not available URL: From Richard.Thomas at the-logic-group.com Tue Oct 29 14:48:32 2013 From: Richard.Thomas at the-logic-group.com (Richard Thomas) Date: Tue, 29 Oct 2013 14:48:32 +0000 Subject: [Pki-users] CA Administrator of Instance pki-ca In-Reply-To: <52616F7F.8030908@redhat.com> References: <574459158D85E14CBBA091C8AD9B44E27B34EFEECF@ms03.GS.TLG.PRIVATE>, <524DA3EE.3080605@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B34EFDF65@ms03.GS.TLG.PRIVATE> <52544E1C.2010308@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AEA5@ms03.GS.TLG.PRIVATE> <52588E08.2010803@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AED7@ms03.GS.TLG.PRIVATE> <525D7038.4010206@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AEF3@ms03.GS.TLG.PRIVATE> <525F3288.8030000@redhat.com> <574459158D85E14CBBA091C8AD9B44E27B3665AF10@ms03.GS.TLG.PRIVATE> <52616F7F.8030908@redhat.com> Message-ID: <574459158D85E14CBBA091C8AD9B44E27B3665AF86@ms03.GS.TLG.PRIVATE> Hi Andrew, Thanks for that, it's been a while before I've been able to try the steps in https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/renewing-subsystem-certificates.html#renewing-certificates-using-certutil Below are the results of those steps. Step 3 resulted in: #certutil -K -d . certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services" Enter Password or Pin for "NSS Certificate DB": < 0> rsa 422b5af15b44ea69130671f9eea3c047c0ad0080 (orphan) < 1> rsa 7ee73faba7c4f1a027f5b309d9175089a8a6f084 Server-Cert cert-pki-ca < 2> rsa 7bfe57e8f1adbe5d00f945be6cb167ce905dac3f ocspSigningCert cert-pki-ca < 3> rsa 78b0a760918b4a9ec312cc75408a23e551dbd615 caSigningCert cert-pki-ca < 4> rsa 99c4c03f6dd0bd4c90933b62c4b023d942f79d9e subsystemCert cert-pki-ca < 5> rsa 9b839620f5d6802fb4c938fe6f06bcc9a1de8a85 auditSigningCert cert-pki-ca Step 4 resulted in: #cp -r /var/lib/pki-ca/alias /tmp/alias/ #cd /tmp/alias/ #certutil -D -n "Server-Cert cert-pki-ca" -d . #certutil -D -n "ocspSigningCert cert-pki-ca" -d . #certutil -D -n "caSigningCert cert-pki-ca" -d . #certutil -D -n "subsystemCert cert-pki-ca" -d . #certutil -D -n "auditSigningCert cert-pki-ca" -d . Step 5 resulted in: #certutil -d . -R -k "NSS Certificate DB:cert-pki-ca" -s "" -a -o .req2.txt certutil: NSS Certificate DB:cert-pki-ca is neither a key-type nor a nickname: security library: bad database. #certutil -d . -R -k "NSS Certificate DB:cert-pki-ca" -s "CN=OCSP Signing Certificate," -a -o OCSP.req2.txt certutil: NSS Certificate DB:cert-pki-ca is neither a key-type nor a nickname: security library: bad database. #certutil -d . -R -k "NSS Certificate DB:cert-pki-ca" -s "CN=" -a -o .req2.txt certutil: NSS Certificate DB:cert-pki-ca is neither a key-type nor a nickname: security library: bad database. #certutil -d . -R -k "NSS Certificate DB:cert-pki-ca" -s "CN=CA Subsystem Certificate," -a -o CASub.req2.txt certutil: NSS Certificate DB:cert-pki-ca is neither a key-type nor a nickname: security library: bad database. #certutil -d . -R -k "NSS Certificate DB:cert-pki-ca" -s "CN=CA Audit Signing Certificate," -a -o CAAudit.req2.txt certutil: NSS Certificate DB:cert-pki-ca is neither a key-type nor a nickname: security library: bad database. # I also tried the blow for the key-type or nickname and got the equivalent results: #certutil -d . -R -k "caSigningCert cert-pki-ca" ...etc #certutil -d . -R -k "ocspSigningCert cert-pki-ca" ...etc #certutil -d . -R -k "Server-Cert cert-pki-ca" ...etc #certutil -d . -R -k "subsystemCert cert-pki-ca" ...etc #certutil -d . -R -k "auditSigningCert cert-pki-ca" ...etc Please could you help me with these errors. Thank you. Richard Thomas Senior Network Engineer direct +44 (0)1252 644 265 switchboard +44 (0)1252 776755 email richard.thomas at the-logic-group.com From: Andrew Wnuk [mailto:awnuk at redhat.com] Sent: 18 October 2013 18:27 To: Richard Thomas Cc: pki-users at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca On 10/17/2013 08:36 AM, Richard Thomas wrote: Hi Andrew, Thanks for that, I've been using certutil on a set of files that I have copied from /var/lib/pki-ca/alias/ to /tmp/alias/ so that I can practice on non live certificate database files. Here is what I have done whilst in the /tmp/alias/ directory: $certutil -d . -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,u $certutil -d . -A -n 'ocspSigningCert cert-pki-ca' -t 'u,u,u' -a -i '/tmp/OCSP Signing Certificate-2013-2014.pem' $certutil -d . -A -n 'subsystemCert cert-pki-ca' -t 'u,u,u' -a -i '/tmp/CA Subsystem Certificate-2013-2014.pem' $certutil -d . -A -n 'caSigningCert cert-pki-ca' -t 'CTu,Cu,Cu' -a -i '/tmp/OCSP Signing Certificate-2013-2014.pem' $certutil -d . -A -n 'Server-Cert cert-pki-ca' -t 'u,u,u' -a -i '/tmp/-2013-2014.pem' $certutil -d . -A -n 'auditSigningCert cert-pki-ca' -t 'u,u,u' -a -i '/tmp/CA Audit Signing Certificate-2013-2014.pem' $certutil -d . -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u ocspSigningCert cert-pki-ca CTu,Cu,Cu OCSP trust bits should stay as "u,u,u" caSigningCert cert-pki-ca CTu,Cu,Cu Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,u Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,u I have a few queries about what I have done.... 1) The old and new certificates are in the database store, so how does DogTag know when to use the old and new certificates? Dogtag requests certificates by nickname. NSS library is providing the best choice based on nickname provided by Dogtag. To avoid any potential problem, you may choose to remove old certificates before importing the new certificates as suggested in the following documentation: https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/renewing-subsystem-certificates.html#renewing-certificates-using-certutil 2) E.G. Would I also have to update each ca..cert= parameter of /etc/pki-ca/CS.cfg with the new b64-encoded certificate? E.G. ca.audit_signing.cert=, ca.ocsp_signing.cert= etc. 3) I notice the following differences between original and new CA Audit Signing Certificates (may be on the others, but haven't looked yet). Is this anything to worry about? Original: Identifier: Authority Key Identifier - 2.5.29.35 Critical: no Key Identifier: Identifier: Key Usage: - 2.5.29.15 Critical: yes Key Usage: Digital Signature Non Repudiation Identifier: Authority Info Access: - 1.3.6.1.5.5.7.1.1 Critical: no Access Description: Method #0: ocsp Location #0: URIName: http://:9180/ca/ocsp Identifier: Extended Key Usage: - 2.5.29.37 Critical: no Extended Key Usage: 1.3.6.1.5.5.7.3.4 New cert that I generated: Extensions: Identifier: Authority Key Identifier - 2.5.29.35 Critical: no Key Identifier: 77:2E:A7:DA:1D:1C:AF:3A:2A:5C:09:02:80:B8:DD:31: 28:05:51:9A Identifier: Subject Key Identifier - 2.5.29.14 Critical: no Key Identifier: B9:B9:F0:09:0C:A2:F3:E4:A2:D3:F6:B9:63:6B:EA:2C: 96:52:22:55 Identifier: Key Usage: - 2.5.29.15 Critical: yes Key Usage: Digital Signature Non Repudiation Key usage is the same so it should work as this is just auditing certificate. Thanks again, Richard Thomas Senior Network Engineer direct +44 (0)1252 644 265 switchboard +44 (0)1252 776755 email richard.thomas at the-logic-group.com From: Andrew Wnuk [mailto:awnuk at redhat.com] Sent: 17 October 2013 01:43 To: Richard Thomas Cc: pki-users at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca On 10/16/2013 06:31 AM, Richard Thomas wrote: Hi Andrew, Thanks for your email, I got past that issue once I made some edits to some .cfg files in /var/lib/pki-ca/profiles/ca/ (shown at the bottom of this email). That meant I could get as far as "Install a certificate" and I got a choice of the following when doing so: o) Certificate Manager CA Signing Certificate(s) o) OCSP Signing Certificate(s) o) SSL Server Certificate(s) o) Cross-signed Certificate(s) o) Other Certificate(s) Please could you let me know which of the above option I should select. The first 3 options should work for your CA but you are missing entries for subsytem and audit certificates. You may import certificates manually using certutil. For this you need to 1. stop your CA 2. change directory to /var/lib/pki-ca/alias/ 3. check current content of CA's NSS-DB by running 4. certutil -d . -L 1. import certificates using identical trust bits and nicknames certutil -d . -A -n '' -t '' -a -i '' 2. start your CA If you need to alter nicknames, please reflect this in CS.cfg file. Thank you. Richard. Here's what I did to be able to "Renew certificate to be manually approved by agents". Edit file /var/lib/pki-ca/profiles/ca/caServerCert.cfg Change: visible=false enable=false To: visible=true enable=true Edit file /var/lib/pki-ca/profiles/ca/caOCSPCert.cfg Change: visible=false enable=false To: visible=true enable=true Edit file /var/lib/pki-ca/profiles/ca/caSignedLogCert.cfg Change: visible=false enable=false To: visible=true enable=true visible=true makes enrollment visible on enrollment list page enable=true enables specific enrollment profile Both changes are fine. service pki-cad restart From: Andrew Wnuk [mailto:awnuk at redhat.com] Sent: 15 October 2013 17:41 To: Richard Thomas Cc: pki-users at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca On 10/15/2013 02:35 AM, Richard Thomas wrote: Hi Andrew, Thanks again for getting back to me. Unfortunately, I didn't get very far. I've shown below what I have done and what it resulted in: o) Go to the :9443/ca/agent/ca URL and list the certificates stored in Dogtag. o) Make a note of of the Certificate Serial Numbers of the following certificates and change the hex value into decimal: CN=OCSP Signing Certificate E.G. 2 CN= E.G. 3 CN=CA Subsystem Certificate E.G. 4 CN=CA Audit Signing Certificate E.G. 5 CN= E.G. 268369921 o) Go to the :9444/ca/ee/ca URL o) Click on "Renewal: Renew certificate to be manually approved by agents" o) Submit each of the Certificate Serial Numbers noted above and make a note of the request ID For each Certificate Serial Number listed above that I submit, I get the following: Sorry, your request is not submitted. The reason is "Profile caServerCert Not Found". Check if caServerCert.cfg is listed under /var/lib/pki-ca/profiles/ca and then check if /var/lib/pki-ca/conf/CS.cfg includes profile.list= . . . ,caServerCert, . . . . . . profile.caServerCert.class_id=caEnrollImpl profile.caServerCert.config=/var/lib/pki-ca/profiles/ca/caServerCert.cfg . . . Please could you help me further. Many thanks. Richard. From: Andrew Wnuk [mailto:awnuk at redhat.com] Sent: 12 October 2013 00:47 To: Richard Thomas Cc: pki-users at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca On 10/11/2013 07:04 AM, Richard Thomas wrote: Hi Andrew, Thanks for those tips, I had some success, then difficulty and then success. Below is what I did, with some of my comments inline. Before I get to that though, there are some other certificates that are due to run out soon, but I think they should be easier to renew. The Common Name of those other certificates are: o) CN=OCSP Signing Certificate o) CN= o) CN=CA Subsystem Certificate o) CN=CA Audit Signing Certificate As I noticed below, that your server provides option to "Renew certificate to be manually approved by agents". You should used this option for all your renewals. Then start pkiconsole go to "System Keys and Certificates", select "Local Certificates", click on "Add/Renew", "Next" and "Install a certificate" Please could you help me and let me know what steps I should take for renewing these too. Thank you. Anyway, back to what I did to get the admin certificate updated. Your steps are still numbered, the ones that I did around them are identified with o) Here goes: o) Edit /var/lib/pki-ca/profiles/ca/caUserCert.cfg Change: visible=false enable=false To: visible=true enable=true o) Restart service "pki-cad" 1. Go to EE interface (typically https://:9444/ca/ee/ca/) and select "Manual User Dual-Use Certificate Enrollment" 2. Fill out the form and submit request 3. Go to Agent interface (typically https://:9443/ca/agent/ca/) and approve submitted request 4. Return to EE interface, select "Retrieval" tab and "Check Request Status". 5. Type in request number and press submit. 6. Click on issued certificate serial number. >I did "List Certificates", went to the last page and found the certificate that way 7. Go to the end of page displaying certificate and press "Import Your Certificate" >I got "The server returned an invalid client certificate. Error 207 (net::ERR_CERT_INVALID)" This probably means that browser which generated certificate request (and the key) is not the same browser used to import certificate. > So having got stuck at this point, I figured I could use what I had done before and then use your pkiconsole instructions. > The below is end-to-end from what I started off on my own and then across to the second half of your instructions. o) Go to the :9444/ca/ee/ca URL o) Click on "Renewal: Renew certificate to be manually approved by agents" (make a note of the number) o) Go to the :9443/ca/agent/ca URL to approve my request. (Use the number above) o) Go to the :9444/ca/ee/ca URL to retrieve the certificate. (Use the number above) and click on the Issued certificate o) Extract the Base 64 encoded part of the certificate and save as .pem o) Transfer .p12 and .pem to a machine with openssl installed on it o) On a machine with openssl installed on it, submit following command: $openssl pkcs12 -in .p12 -out .pem -nodes o) Copy .pem to .pem o) Update .pem by replacing the relevant part of it with the contents of .pem o) Cut the key part of .pem and create .key from it o) Submit following command: $openssl pkcs12 -export -in .pem -inkey .key -out .p12 o) Transfer .p12 to the machine with the web browser that you want to access Dog Tag from. o) Import .p12 into the machine. 8. Start pkiconsole (typically by running "pkiconsole https://`hostname`:9445/ca") 9. Select "Users and Groups" and select your admin entry. 10. Press "Certificates" button then "Import" and paste in the contents of .pem, then OK and "Done" 11. Clear SSL cache in the browser or restart your browser. 12. You should now be able to use your new certificate to access Agent interface >YES - I can now access the agent interface using the new certificate J From: Andrew Wnuk [mailto:awnuk at redhat.com] Sent: 08 October 2013 19:26 To: Richard Thomas Cc: pki-users-bounces at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca On 10/07/2013 11:41 AM, Richard Thomas wrote: Hi Andrew, Thanks very much for sending this to me. The first thing I'd like to point out is that I'm using the pre-Red Hat enterprise variant of DogTag (dogtag-pki-1.3.0-2.el5) I have been trying to adapt the instructions as best I can and have so nearly got there, but not quite.. I have been referring to chapter 4.8.2 of that article by going to the :9444/ca/ee/ca URL and the only 2 Certificate Profiles I have to choose from are: o) Renewal: Renew certificate to be manually approved by agents o) Cisco VPN Client Enrolment The second option is for end users of our Cisco VPN to generate new certificates with, so I don't do anything with that. The first option looked promising, as it asked for a certificate number, so I used the :9443/ca/agent/ca URL to find the certificate number of the current "CA Administrator of Instance pki-ca" certificate, make a note of it and enter it into the certificate renewal page. I then use the :9443/ca/agent/ca URL to approve my request. Back to the :9444/ca/ee/ca URL to retrieve the certificate. I then updated the .p12 (.pfx) certificate with the one that appeared from the step above, with quite a bit of open_ssl commands, but I am confident that my new .p12 has everything in it as before (including the private key), with the exception of the "CA Administrator of Instance pki-ca" certificate being my updated one instead of the current one. I manage to import it into by machine's browser and when I navigate to :9443/ca/agent/ca, the new certificate comes up as an option to present to Dog Tag, so things are looking good at this stage and I select it. After that is where the first thing looks different, but I wasn't too worried about. I get a message saying "Request For Permission to Use a Key", so I grant permission. Then things don't look go at all, as once I'm past that, all the pages say "Invalid Credential". I have probably gone about things in a way that's more complicated than it should be and I guess it's because I'm using an earlier version of Dog Tag. Do you have any ideas where I have gone wrong with this please. Thank you very much. Richard. Unfortunately your version is old enough to miss new renewal profiles, which would make your task easier. Here is a simple way to renew your CA administrator certificate: 1. Go to EE interface (typically https://:9444/ca/ee/ca/) and select "Manual User Dual-Use Certificate Enrollment" 2. Fill out the form and submit request 3. Go to Agent interface (typically https://:9443/ca/agent/ca/) and approve submitted request 4. Return to EE interface, select "Retrieval" tab and "Check Request Status". 5. Type in request number and press submit. 6. Click on issued certificate serial number. 7. Go to the end of page displaying certificate and press "Import Your Certificate" 8. Start pkiconsole (typically by running "pkiconsole https://`hostname`:9445/ca") 9. Select "Users and Groups" and select your admin entry. 10. Press "Certificates" button then "Import" and paste in your new base64 encoded certificate, then OK and "Done" 11. Clear SSL cache in the browser or restart your browser. 12. You should now be able to use your new certificate to access Agent interface Thanks, Andrew ________________________________________ From: pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] On Behalf Of Andrew Wnuk [awnuk at redhat.com] Sent: Thursday, October 03, 2013 6:05 PM To: pki-users at redhat.com Subject: Re: [Pki-users] CA Administrator of Instance pki-ca Hi Richard, You can renew certificate using: https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/renewing-certificates.html and then add new certificate to CA administrator entry using console. Best, Andrew On 10/03/2013 08:49 AM, Richard Thomas wrote: Hi all, I hope someone would be able to help me with this. I have taken over a Dog Tag system and I have little knowledge of it. I need to renew the "CA Administrator of Instance pki-ca" certificate, as it is running out in a few weeks. Would someone be able to point me in the direction of any documentation on how to do this or let me know how to do it. I would massively appreciate any guidance on this. Thanks in advance, Richard. The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [cid:image001.jpg at 01CED4B1.64DF78B0] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [cid:image001.jpg at 01CED4B1.64DF78B0] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. The world's first PCI accreditation for a Point to Point Encryption application. Find out more... The Logic Group Enterprises Limited Logic House Waterfront Business Park Fleet, Hampshire GU51 3SB United Kingdom phone fax email web +44 1252 776 700 +44 1252 776 738 info at the-logic-group.com www.the-logic-group.com Registered in England Number 2609323 [http://www.the-logic-group.com/UploadedImages/34e428b6-82a8-46f4-999d-89403051ff3c.jpg] The Logic Group Enterprises Limited, Logic House, Waterfront Business Park, Fleet Road, Fleet, Hampshire, GU51 3SB, United Kingdom. Registered in England. Registered No. 2609323 The information in this email and any attachments are confidential and may be legally privileged and protected by law. It is for the intended recipient only. If you are not the intended recipient you may not use, disclose, copy, distribute, print or rely on the content of this email or its attachments. If this email has been received by you in error please advise the sender and delete the email from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 895 bytes Desc: image001.jpg URL: From jindrich.dolezal at adaptivemobile.com Tue Oct 1 13:13:48 2013 From: jindrich.dolezal at adaptivemobile.com (Jindrich Dolezal) Date: Tue, 01 Oct 2013 13:13:48 -0000 Subject: [Pki-users] pki-ca-9.0.3-30 setup In-Reply-To: <1193695098.31145.1380628189114.JavaMail.root@mail02.philasd.org> References: <1193695098.31145.1380628189114.JavaMail.root@mail02.philasd.org> Message-ID: <524ACA87.3060009@adaptivemobile.com> hi, there are some themes installed : [root at jdrhel2 pki-ca]# rpm -qa | grep pki | grep theme ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-pki-common-theme-9.0.3-7.el6.noarch do we need some more themes? thanks jd On 10/01/2013 01:49 PM, Taggart, Michelle wrote: > I believe you'll have to also install a theme. On the CentOS package, themes are not included. > > > Thanks, > > Michelle T > > ----- Original Message ----- > From: Oleg Antonenko > To: pki-users at redhat.com > Cc: Jindrich Dolezal , Ciaran Bradley > Sent: Tue, 01 Oct 2013 07:08:38 -0400 (EDT) > Subject: [Pki-users] pki-ca-9.0.3-30 setup > > Hello there! > Could you help with the CA setup please? > > We installed a new machine with CentOS release 6.4 (Final) and installed the pki-ca-9.0.3-30 package. > The command we used for creation was: > > pkicreate -pki_instance_root=/var/lib > -pki_instance_name=pki-ca > -subsystem_type=ca > -agent_secure_port=9443 > -ee_secure_port=9444 > -ee_secure_client_auth_port=9446 > -admin_secure_port=9445 > -unsecure_port=9180 > -tomcat_server_port=9701 > -user=pkiuser > -group=pkiuser > -redirect conf=/etc/pki-ca > -redirect logs=/var/log/pki-ca > -verbose > > After clicking through the wizard and restarting the service: > > status: > [root at jdrhel2 ~]# /sbin/service pki-cad status pki-ca > pki-ca (pid 4988) is running... [ OK ] > Unsecure Port = http://jdrhel2:9180/ca/ee/ca > Secure Agent Port = https://jdrhel2:9443/ca/agent/ca > Secure EE Port = https://jdrhel2:9444/ca/ee/ca > Secure Admin Port = https://jdrhel2:9445/ca/services > EE Client Auth Port = https://jdrhel2:9446/ca/eeca/ca > PKI Console Port = pkiconsole https://jdrhel2:9445/ca > Tomcat Port = 9701 (for shutdown) > > PKI Instance Name: pki-ca > PKI Subsystem Type: Root CA (Security Domain) > > Registered PKI Security Domain Information: > ========================================================================== > Name: AMSDomain > URL: https://jdrhel2:9445 > ========================================================================== > > Everything seems to be running, but when i connect to the adresses above, i can see firefox is verifying server certificate, uses personal certificate, but then the page is empty. > To be precise, there are just two links leading to empty pages: > - link 'SSL End Users Services' pointing at https://jdrhel2:9444/ca/ee/ca and > - link 'Agent Services' pointing at https://jdrhel2:9443/ca/agent/ca > > Is there anything we did wrong or forgot to configure? > > Many thanks, > Oleg > > > > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users >