From edewata at redhat.com Fri Jul 1 02:47:09 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 30 Jun 2016 21:47:09 -0500 Subject: [Pki-users] Intermediate CA In-Reply-To: <3ddc100e-3636-313d-cb00-ec3923ccf40d@systemonenoc.com> References: <3ddc100e-3636-313d-cb00-ec3923ccf40d@systemonenoc.com> Message-ID: On 6/29/2016 5:10 AM, Carlos Barrabes wrote: > Hello, > > Im trying to create an intermediate CA so I can issue certificates with > a trust path pointing to our RootCA but I'm facing some issues while > following the documentation in the project's site. > > Once I'm done with step two, you import the external and ca-signing > certificates into a users NSS db and then the wiki says you have to > import the CA admin certificate and key but the problem is there is no > such thing after starting the instance via custom config file or I > simply cannot find them. > > Any suggestions? > > Thanks for your time! > > I am running Dogtag 10.2.6-12 on a Fedora 22 server machine and the > prodecure Im following is this one: > http://pki.fedoraproject.org/wiki/Installing_CA_with_Externaly-Signed_CA_Certificate Hi, At the end of the PKI server installation the admin certificate and key will be stored in a PKCS #12 file and the location should be displayed in the final installation message. Usually it is stored in this location: /root/.dogtag/pki-tomcat/ca_admin_cert.p12 But that could change depending on your deployment configuration that you supplied to pkispawn. After the PKI server installation you can set up the PKI client to manage CA services. First initialize the client: $ pki -c Secret123 client-init Then import the root CA certificate: $ pki -c Secret123 client-cert-import "Root CA Certificate" --ca-cert root-ca.crt Then import the PKI CA certificate: $ pki -c Secret123 client-cert-import "PKI CA Certificate" --ca-cert ca_signing.crt Then import the CA admin certificate & key: $ pki -c Secret123 client-cert-import caadmin --pkcs12 /root/.dogtag/pki-tomcat/ca_admin_cert.p12 --pkcs12-password-file /root/.dogtag/pki-tomcat/ca/pkcs12_password.conf Then you should be able to access CA services as the admin, for example: $ pki -c Secret123 -n caadmin ca-user-find Just let me know if you have any question. -- Endi S. Dewata From cbarrabes at systemonenoc.com Thu Jul 7 14:14:39 2016 From: cbarrabes at systemonenoc.com (Carlos Barrabes) Date: Thu, 7 Jul 2016 16:14:39 +0200 Subject: [Pki-users] Intermediate CA In-Reply-To: References: <3ddc100e-3636-313d-cb00-ec3923ccf40d@systemonenoc.com> Message-ID: Hello, it turns out that something was wrong with my test environment because I was receiving random errors when launching the instance and everything has been working great after moving to a new, clean virtual machine. Also, your response pointed me to look at the config file and I realized there was no default admin certificate path defined so I added the following line: pki_client_admin_cert = /tmp/ca_admin.cert However, regardless of the path I define there it always gets saved to the default /root/.dogtag/intca/ca_admin.cert so I'm not sure to be using the option properly. Its not a big deal, but I think it worth metioning anyway. Other than that everything has been working great so far so thanks again for pointing me in the right direction. Regards! On 07/01/2016 04:47 AM, Endi Sukma Dewata wrote: > On 6/29/2016 5:10 AM, Carlos Barrabes wrote: >> Hello, >> >> Im trying to create an intermediate CA so I can issue certificates with >> a trust path pointing to our RootCA but I'm facing some issues while >> following the documentation in the project's site. >> >> Once I'm done with step two, you import the external and ca-signing >> certificates into a users NSS db and then the wiki says you have to >> import the CA admin certificate and key but the problem is there is no >> such thing after starting the instance via custom config file or I >> simply cannot find them. >> >> Any suggestions? >> >> Thanks for your time! >> >> I am running Dogtag 10.2.6-12 on a Fedora 22 server machine and the >> prodecure Im following is this one: >> http://pki.fedoraproject.org/wiki/Installing_CA_with_Externaly-Signed_CA_Certificate >> > > Hi, > > At the end of the PKI server installation the admin certificate and > key will be stored in a PKCS #12 file and the location should be > displayed in the final installation message. Usually it is stored in > this location: > > /root/.dogtag/pki-tomcat/ca_admin_cert.p12 > > But that could change depending on your deployment configuration that > you supplied to pkispawn. > > After the PKI server installation you can set up the PKI client to > manage CA services. First initialize the client: > > $ pki -c Secret123 client-init > > Then import the root CA certificate: > > $ pki -c Secret123 client-cert-import "Root CA Certificate" --ca-cert > root-ca.crt > > Then import the PKI CA certificate: > > $ pki -c Secret123 client-cert-import "PKI CA Certificate" --ca-cert > ca_signing.crt > > Then import the CA admin certificate & key: > > $ pki -c Secret123 client-cert-import caadmin --pkcs12 > /root/.dogtag/pki-tomcat/ca_admin_cert.p12 --pkcs12-password-file > /root/.dogtag/pki-tomcat/ca/pkcs12_password.conf > > Then you should be able to access CA services as the admin, for example: > > $ pki -c Secret123 -n caadmin ca-user-find > > Just let me know if you have any question. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From techpkiuser at gmail.com Wed Jul 13 11:57:12 2016 From: techpkiuser at gmail.com (Kamal Perera) Date: Wed, 13 Jul 2016 17:27:12 +0530 Subject: [Pki-users] base64 CMC Request format In-Reply-To: <85C87A9995875247B2DD471950E0AE4D1B5C3F09@M0182.s-mxs.net> References: <85C87A9995875247B2DD471950E0AE4D1B5BAE40@M0182.s-mxs.net> <524C6EDC.6010908@redhat.com> <85C87A9995875247B2DD471950E0AE4D1B5BEE4F@M0182.s-mxs.net> <524DE09B.1010806@redhat.com> <85C87A9995875247B2DD471950E0AE4D1B5C3F09@M0182.s-mxs.net> Message-ID: Dear All, sorry for taking this old post in to focus. I'm trying to create a CMC enrolment process with our DogTag CA. Can someone advice me how to create a CMCRequest.A sample configuration would be much helpful. On Fri, Oct 4, 2013 at 3:38 PM, Elliott William C OSS sIT < WilliamC.Elliott at s-itsolutions.at> wrote: > 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= b64-encoded/url-encoded 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:// host:port>/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 > > > > _______________________________________________ > 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 Wed Jul 13 20:41:23 2016 From: cfu at redhat.com (Christina Fu) Date: Wed, 13 Jul 2016 13:41:23 -0700 Subject: [Pki-users] base64 CMC Request format In-Reply-To: References: <85C87A9995875247B2DD471950E0AE4D1B5BAE40@M0182.s-mxs.net> <524C6EDC.6010908@redhat.com> <85C87A9995875247B2DD471950E0AE4D1B5BEE4F@M0182.s-mxs.net> <524DE09B.1010806@redhat.com> <85C87A9995875247B2DD471950E0AE4D1B5C3F09@M0182.s-mxs.net> Message-ID: Hi Kamel, Just type CMCRequest at command line and it will spit out a sample config file which you can take and modify. It contains comments where you can find out more info. hope this helps. Christina On 07/13/2016 04:57 AM, Kamal Perera wrote: > Dear All, > > sorry for taking this old post in to focus. > > I'm trying to create a CMC enrolment process with our DogTag CA. Can > someone advice me how to create a CMCRequest.A sample configuration > would be much helpful. > > > > On Fri, Oct 4, 2013 at 3:38 PM, Elliott William C OSS sIT > > wrote: > > 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= b64-encoded/url-encoded 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:// host:port>/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 > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascal.jakobi at gmail.com Tue Jul 19 08:55:13 2016 From: pascal.jakobi at gmail.com (Pascal Jakobi) Date: Tue, 19 Jul 2016 10:55:13 +0200 Subject: [Pki-users] Dogtag / Tomcat In-Reply-To: References: Message-ID: Trying to install Dogtag on an F23 VM. Seems that tomcat stops when running : *[root at pki ~]# systemctl status tomcat* ? tomcat.service - Apache Tomcat Web Application Container Loaded: loaded (/usr/lib/systemd/system/tomcat.service; enabled; vendor preset: disabled) Active: active (*running*) since Tue 2016-07-19 10:49:18 CEST; 2s ago Process: 1330 ExecStop=/usr/libexec/tomcat/server stop (code=exited, status=1/FAILURE) Main PID: 1599 (java) CGroup: /system.slice/tomcat.service ??1599 /usr/lib/jvm/jre/bin/java -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory -classpath /usr/share/tom... Jul 19 10:49:19 pki.home server[1599]: ... 13 more Jul 19 10:49:19 pki.home server[1599]: 19-Jul-2016 10:49:19.610 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolH...io-8009"] Jul 19 10:49:19 pki.home server[1599]: 19-Jul-2016 10:49:19.625 INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector U...rite/read Jul 19 10:49:19 pki.home server[1599]: 19-Jul-2016 10:49:19.629 INFO [main] org.apache.catalina.startup.Catalina.load Initialization proce...in 808 ms Jul 19 10:49:19 pki.home server[1599]: 19-Jul-2016 10:49:19.668 INFO [main] org.apache.catalina.core.StandardService.startInternal Startin... Catalina Jul 19 10:49:19 pki.home server[1599]: 19-Jul-2016 10:49:19.669 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting...at/8.0.32 Jul 19 10:49:19 pki.home server[1599]: 19-Jul-2016 10:49:19.682 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deploy...t-manager Jul 19 10:49:20 pki.home server[1599]: 19-Jul-2016 10:49:20.513 INFO [localhost-startStop-1] org.apache.jasper.servlet.TldScanner.scanJars At least... Jul 19 10:49:20 pki.home server[1599]: 19-Jul-2016 10:49:20.600 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deploy...in 917 ms Jul 19 10:49:20 pki.home server[1599]: 19-Jul-2016 10:49:20.601 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deploy...s/manager Hint: Some lines were ellipsized, use -l to show in full. *[root at pki ~]# systemctl restart pki-tomcatd at pki-tomcat.service** **[root at pki ~]# systemctl status tomcat* ? tomcat.service - Apache Tomcat Web Application Container Loaded: loaded (/usr/lib/systemd/system/tomcat.service; enabled; vendor preset: disabled) Active: inactive (*dead*) since Tue 2016-07-19 10:49:21 CEST; 8s ago Process: 1638 ExecStop=/usr/libexec/tomcat/server stop (code=exited, status=0/SUCCESS) Process: 1599 ExecStart=/usr/libexec/tomcat/server start (code=exited, status=0/SUCCESS) Main PID: 1599 (code=exited, status=0/SUCCESS) Jul 19 10:49:21 pki.home server[1599]: 19-Jul-2016 10:49:21.148 INFO [main] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandl...io-8009"] Jul 19 10:49:21 pki.home server[1599]: 19-Jul-2016 10:49:21.149 INFO [main] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandl...io-8080"] Jul 19 10:49:21 pki.home server[1599]: 19-Jul-2016 10:49:21.150 INFO [main] org.apache.coyote.AbstractProtocol.destroy Destroying Protocol...io-8080"] Jul 19 10:49:21 pki.home server[1599]: 19-Jul-2016 10:49:21.151 INFO [main] org.apache.coyote.AbstractProtocol.destroy Destroying Protocol...io-8009"] Jul 19 10:49:21 pki.home server[1638]: Java virtual machine used: /usr/lib/jvm/jre/bin/java Jul 19 10:49:21 pki.home server[1638]: classpath used: /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/lib/...aemon.jar Jul 19 10:49:21 pki.home server[1638]: main class used: org.apache.catalina.startup.Bootstrap Jul 19 10:49:21 pki.home server[1638]: flags used: -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory Jul 19 10:49:21 pki.home server[1638]: options used: -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.d...ogManager Jul 19 10:49:21 pki.home server[1638]: arguments used: stop Hint: Some lines were ellipsized, use -l to show in full. This should be known, isnt'it ? Pls advise... -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Tue Jul 19 16:59:47 2016 From: jmagne at redhat.com (John Magne) Date: Tue, 19 Jul 2016 12:59:47 -0400 (EDT) Subject: [Pki-users] Dogtag / Tomcat In-Reply-To: References: Message-ID: <1336658623.9991707.1468947587708.JavaMail.zimbra@redhat.com> The info here is not much to go on. Could you possibly post some of the CA's log "debug" to see if there is some error inside the CA causing tomcat to not start. ----- Original Message ----- > From: "Pascal Jakobi" > To: pki-users at redhat.com > Sent: Tuesday, 19 July, 2016 1:55:13 AM > Subject: [Pki-users] Dogtag / Tomcat > > Trying to install Dogtag on an F23 VM. > Seems that tomcat stops when running : > > > > [root at pki ~]# systemctl status tomcat > ? tomcat.service - Apache Tomcat Web Application Container > Loaded: loaded (/usr/lib/systemd/system/tomcat.service; enabled; vendor > preset: disabled) > Active: active ( running ) since Tue 2016-07-19 10:49:18 CEST; 2s ago > Process: 1330 ExecStop=/usr/libexec/tomcat/server stop (code=exited, > status=1/FAILURE) > Main PID: 1599 (java) > CGroup: /system.slice/tomcat.service > ??1599 /usr/lib/jvm/jre/bin/java > -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory > -classpath /usr/share/tom... > > Jul 19 10:49:19 pki.home server[1599]: ... 13 more > Jul 19 10:49:19 pki.home server[1599]: 19-Jul-2016 10:49:19.610 INFO [main] > org.apache.coyote.AbstractProtocol.init Initializing ProtocolH...io-8009"] > Jul 19 10:49:19 pki.home server[1599]: 19-Jul-2016 10:49:19.625 INFO [main] > org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector U...rite/read > Jul 19 10:49:19 pki.home server[1599]: 19-Jul-2016 10:49:19.629 INFO [main] > org.apache.catalina.startup.Catalina.load Initialization proce...in 808 ms > Jul 19 10:49:19 pki.home server[1599]: 19-Jul-2016 10:49:19.668 INFO [main] > org.apache.catalina.core.StandardService.startInternal Startin... Catalina > Jul 19 10:49:19 pki.home server[1599]: 19-Jul-2016 10:49:19.669 INFO [main] > org.apache.catalina.core.StandardEngine.startInternal Starting...at/8.0.32 > Jul 19 10:49:19 pki.home server[1599]: 19-Jul-2016 10:49:19.682 INFO > [localhost-startStop-1] > org.apache.catalina.startup.HostConfig.deploy...t-manager > Jul 19 10:49:20 pki.home server[1599]: 19-Jul-2016 10:49:20.513 INFO > [localhost-startStop-1] org.apache.jasper.servlet.TldScanner.scanJars At > least... > Jul 19 10:49:20 pki.home server[1599]: 19-Jul-2016 10:49:20.600 INFO > [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deploy...in > 917 ms > Jul 19 10:49:20 pki.home server[1599]: 19-Jul-2016 10:49:20.601 INFO > [localhost-startStop-1] > org.apache.catalina.startup.HostConfig.deploy...s/manager > Hint: Some lines were ellipsized, use -l to show in full. > [root at pki ~]# systemctl restart pki-tomcatd at pki-tomcat.service > [root at pki ~]# systemctl status tomcat > ? tomcat.service - Apache Tomcat Web Application Container > Loaded: loaded (/usr/lib/systemd/system/tomcat.service; enabled; vendor > preset: disabled) > Active: inactive ( dead ) since Tue 2016-07-19 10:49:21 CEST; 8s ago > Process: 1638 ExecStop=/usr/libexec/tomcat/server stop (code=exited, > status=0/SUCCESS) > Process: 1599 ExecStart=/usr/libexec/tomcat/server start (code=exited, > status=0/SUCCESS) > Main PID: 1599 (code=exited, status=0/SUCCESS) > > Jul 19 10:49:21 pki.home server[1599]: 19-Jul-2016 10:49:21.148 INFO [main] > org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandl...io-8009"] > Jul 19 10:49:21 pki.home server[1599]: 19-Jul-2016 10:49:21.149 INFO [main] > org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandl...io-8080"] > Jul 19 10:49:21 pki.home server[1599]: 19-Jul-2016 10:49:21.150 INFO [main] > org.apache.coyote.AbstractProtocol.destroy Destroying Protocol...io-8080"] > Jul 19 10:49:21 pki.home server[1599]: 19-Jul-2016 10:49:21.151 INFO [main] > org.apache.coyote.AbstractProtocol.destroy Destroying Protocol...io-8009"] > Jul 19 10:49:21 pki.home server[1638]: Java virtual machine used: > /usr/lib/jvm/jre/bin/java > Jul 19 10:49:21 pki.home server[1638]: classpath used: > /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/lib/...aemon.jar > Jul 19 10:49:21 pki.home server[1638]: main class used: > org.apache.catalina.startup.Bootstrap > Jul 19 10:49:21 pki.home server[1638]: flags used: > -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory > Jul 19 10:49:21 pki.home server[1638]: options used: > -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat > -Djava.endorsed.d...ogManager > Jul 19 10:49:21 pki.home server[1638]: arguments used: stop > Hint: Some lines were ellipsized, use -l to show in full. > > > This should be known, isnt'it ? Pls advise... > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From beard.lionel at gmail.com Fri Jul 22 15:47:24 2016 From: beard.lionel at gmail.com (Lionel Beard) Date: Fri, 22 Jul 2016 17:47:24 +0200 Subject: [Pki-users] Unable to spawn CA when using HSM In-Reply-To: <568E9F29.1090207@redhat.com> References: <568E9F29.1090207@redhat.com> Message-ID: Hi, Sorry for being soooo long to respond, but I have to switch to another project meanwhile. I'm trying again to use dogtag with a HSM (with SoftHSM v2.1 this time, because I don't have hardware HSM anymore), and with a fresh new installation (server + dogtag), I still have the same issue during pkispawn - s CA: pkispawn : INFO ....... configuring PKI configuration data. pkispawn : ERROR ....... Exception from Java Configuration Servlet: 400 Client Error: Bad Request for url: https://dogtag-ca.qt.cls.fr:8443/ca/rest/installer/configure pkispawn : ERROR ....... ParseError: not well-formed (invalid token): line 1, column 0: {"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.BadRequestException","Code":400,"Message":"Invalid Token provided. No such token."} My CA config file looks like that: [DEFAULT] pki_admin_password=Secret123 pki_client_pkcs12_password=Secret123 pki_ds_password=Secret123 # Optionally keep client databases pki_client_database_purge=False # Provide HSM parameters pki_hsm_enable=True pki_hsm_libfile=/usr/local/lib/softhsm/libsofthsm2.so pki_hsm_modulename=softhsm pki_token_name=dogtag1 pki_token_password=hsm_passwd # Provide PKI-specific HSM token names pki_audit_signing_token=dogtag1 pki_ssl_server_token=dogtag1 pki_subsystem_token=dogtag1 [CA] # Provide CA-specific HSM token names pki_ca_signing_token=dogtag1 pki_ocsp_signing_token=dogtag1 /var/lib/pki/pki-tomcat/ca/logs/debug: [22/Jul/2016:15:36:12][http-bio-8443-exec-3]: SystemConfigService: configure() [22/Jul/2016:15:36:12][http-bio-8443-exec-3]: SystemConfigService: request: ConfigurationRequest [pin=XXXX, token=dogtag1, tokenPassword=XXXX, securityDomainType=newdomain, securityDomainUri=null, securityDomainName= qt.cls.fr Security Domain, securityDomainUser=null, securityDomainPassword=XXXX, isClone=false, cloneUri=null, subsystemName=CA dogtag-ca.qt.cls.fr 8443, p12File=null, p12Password=XXXX, hierarchy=root, dsHost=dogtag-ca.qt.cls.fr, dsPort=389, baseDN=o=pki-CLS-CA, bindDN=cn=Directory Manager, bindpwd=XXXX, database=pki-CLS-CA, secureConn=false, removeData=true, replicateSchema=null, masterReplicationPort=null, cloneReplicationPort=null, replicationSecurity=null, systemCertsImported=false, systemCerts=[com.netscape.certsrv.system.SystemCertData at 60c8305a, com.netscape.certsrv.system.SystemCertData at 7774cd87, com.netscape.certsrv.system.SystemCertData at 6f41ab06, com.netscape.certsrv.system.SystemCertData at 99112a8, com.netscape.certsrv.system.SystemCertData at 28fab920], issuingCA=null, backupKeys=false, backupPassword=, adminCertRequestType=pkcs10, adminSubjectDN=cn=PKI Administrator,e=caadmin at qt.cls.fr,o=qt.cls.fr Security Domain, adminName=caadmin, adminProfileID=caAdminCert, adminCert=null, importAdminCert=false, generateServerCert=true, external=false, standAlone=false, stepTwo=false, authdbBaseDN=null, authdbHost=null, authdbPort=null, authdbSecureConn=null, caUri=null, kraUri=null, tksUri=null, enableServerSideKeyGen=null, importSharedSecret=null, generateSubsystemCert=true, sharedDB=false, sharedDBUserDN=null, createNewDB=true, setupReplication=null, subordinateSecurityDomainName=null, reindexData=null] [22/Jul/2016:15:36:12][http-bio-8443-exec-3]: === Token Authentication === [22/Jul/2016:15:36:12][http-bio-8443-exec-3]: Invalid Token provided. No such token. Versions: Fedroa 24 Dogtag 10.3.3 (also tested with 10.3.3.3 from git repo) Does anyone have an idea? Thanks! Regards 2016-01-07 18:23 GMT+01:00 Christina Fu : > you could normally find more accurate log info giving out more clue under > /logs/debug, e.g. /var/lib/ pki/pki-tomcat/ca/logs/debug > > Christina > > > On 01/06/2016 01:54 AM, Lionel Beard wrote: > > Hi, > > I'm trying to create a CA with a Atos/Bull HSM backend. > I have created a configuration file default_hsm.cfg with hsm options > enabled and configured, and I have set HSM token and password. > > When I run the command: > # pkispawn -s CA -f /etc/pki/default_hsm.cfg -vvv > I get the error: > > pkispawn : DEBUG ........... standalone="no"?>0CArunning10.2.6-13.fc23 > pkispawn : INFO ....... constructing PKI configuration data. > pkispawn : INFO ....... executing 'certutil -R -d > /root/.dogtag/pki-tomcat/ca/alias -s cn=PKI Administrator,e=caadmin at cls.fr > ,o=cls.fr Security Domain -k rsa -g 2048 -z > /root/.dogtag/pki-tomcat/ca/alias/noise -f > /root/.dogtag/pki-tomcat/ca/password.conf -o > /root/.dogtag/pki-tomcat/ca/alias/admin_pkcs10.bin' > pkispawn : INFO ....... rm -f > /root/.dogtag/pki-tomcat/ca/alias/noise > pkispawn : INFO ....... BtoA > /root/.dogtag/pki-tomcat/ca/alias/admin_pkcs10.bin > /root/.dogtag/pki-tomcat/ca/alias/admin_pkcs10.bin.asc > pkispawn : INFO ....... configuring PKI configuration data. > pkispawn : ERROR ....... Exception from Java Configuration Servlet: > 400 Client Error: Bad Request for url: > > https://freeipa-ca.cls.fr:8443/ca/rest/installer/configure > pkispawn : ERROR ....... ParseError: not well-formed (invalid > token): line 1, column 0: > {"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.BadRequestException","Code":400,"Message":"*Invalid > Token provided. No such token*."} > pkispawn : DEBUG ....... Error Type: ParseError > pkispawn : DEBUG ....... Error Message: not well-formed (invalid > token): line 1, column 0 > pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 597, in > main > rv = instance.spawn(deployer) > File > "/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/configuration.py", > line 116, in spawn > json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) > File > "/usr/lib/python2.7/site-packages/pki/server/deployment/pkihelper.py", line > 3872, in configure_pki_data > root = ET.fromstring(e.response.text) > File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1300, in XML > parser.feed(text) > File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1642, in feed > self._raiseerror(v) > File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1506, in > _raiseerror > raise err > > > Installation failed. > > Just after pki service restart. > I don't know which "Token" is it talking about, not sure it is HSM token. > HSM is working fine because it is previously added to database with > modutil: > > # modutil -list -dbdir /etc/pki/pki-tomcat/alias -nocertdb > > Bull TrustWay Proteccio NetHSM 2.4 > > Configuration read from /etc/proteccio//proteccio.rc > > Listing of PKCS #11 Modules > ----------------------------------------------------------- > 1. NSS Internal PKCS #11 Module > slots: 2 slots attached > status: loaded > > slot: NSS Internal Cryptographic Services > token: NSS Generic Crypto Services > > slot: NSS User Private Key and Certificate Services > token: NSS Certificate DB > > 2. nethsm > library name: /usr/lib64/libnethsm.so > slots: 8 slots attached > status: loaded > > slot: Trustway Crypto Engine Slot > token: nethsm1_V1 > > slot: Trustway Crypto Engine Slot > token: > > slot: Trustway Crypto Engine Slot > token: > > slot: Trustway Crypto Engine Slot > token: > > slot: Trustway Crypto Engine Slot > token: > > slot: Trustway Crypto Engine Slot > token: > > slot: Trustway Crypto Engine Slot > token: > > slot: Trustway Crypto Engine Slot > token: > ----------------------------------------------------------- > > Of course, I have updated default_hsm.cfg file according to Redhat > documentation to enable HSM et put HSM token name and password: > # grep hsm /etc/pki/default_hsm.cfg > pki_audit_signing_token=nethsm1_V1 > pki_hsm_enable=True > pki_hsm_libfile=/usr/lib64/libnethsm.so > pki_hsm_modulename=nethsm > pki_ssl_server_token=nethsm1_V1 > pki_subsystem_token=nethsm1_V1 > pki_token_name=nethsm1_V1 > pki_storage_token=nethsm1_V1 > pki_transport_token=nethsm1_V1 > > I have tried with interactive installation (so with no HSM), and it is > working fine. > > Does anyone can help me? > > Thanks! > > > _______________________________________________ > Pki-users mailing listPki-users at redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at datasages.com Fri Jul 22 17:35:13 2016 From: david at datasages.com (David Kinghorn) Date: Fri, 22 Jul 2016 13:35:13 -0400 Subject: [Pki-users] Jar files versions for java pki client Message-ID: Hi, I'm trying to use the java client in the link below (using nss authentication), but I'm running into issues finding the right versions of the various jar files listed. http://pki.fedoraproject.org/wiki/Java_Key_Client_API#Setting_up_Buildpath.2FClasspath I am getting inundated NoClassDefFoundError, IncompatibleClassChangeError and the like presumably due to the wrong version of certain jar files. Is there a guide on which version of the various files are required? In particular, I'm having an issue with conflicts between the following two dependencies, but there are probably more. javax.ws.rs javax.ws.rs-api 2.0-m12 org.jboss.resteasy resteasy-client 3.0.18.Final This is on Red Hat Enterprise Linux Server release 7.2 (Maipo) with jss-4.2.6-37.el7.x86_64 and pki 10.2.5.6 I am using java 7 on tomcat 7 using maven to build the war file Thanks, ~ David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at datasages.com Mon Jul 25 20:15:30 2016 From: david at datasages.com (David Kinghorn) Date: Mon, 25 Jul 2016 16:15:30 -0400 Subject: [Pki-users] Unknown Certificate Request Type error on enrolling PKCS10 csr in java Message-ID: Hey guys, I'm trying to upload a csr to the ca in java and am getting a "Unknown Certificate Request Type" error. There seems to be no documentation on this. Any help what I'm doing wrong would be great. My code is as follows: MultivaluedMap enrollmentRequestMap = new MultivaluedMapImpl(); enrollmentRequestMap.add("cert_request_type", "pkcs10"); enrollmentRequestMap.add("cert_request", certData); CertEnrollmentRequest enrollmentRequest = new CertEnrollmentRequest( enrollmentRequestMap); enrollmentRequest.setProfileId(config.getRemoteAssetCertProfileId()); CertRequestInfos result = client.enrollRequest(enrollmentRequest); Thanks, ~ David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.pereira at gps-pamcary.com.br Tue Jul 26 13:01:55 2016 From: sergio.pereira at gps-pamcary.com.br (=?iso-8859-1?Q?S=E9rgio_Pereira?=) Date: Tue, 26 Jul 2016 10:01:55 -0300 Subject: [Pki-users] setting up Directory-based authentication Message-ID: <01b901d1e73d$e31301b0$a9390510$@gps-pamcary.com.br> Hi there, I?m having a hard time setting up the directory-based authentication for dogtag 10.3.3-1. I did follow the instructions as http://pki.fedoraproject.org/wiki/Directory-Authenticated_Profiles and I get an error when trying to bind/authenticate against directory service (Microsoft AD2008) as follows: [26/Jul/2016:08:27:27][http-bio-8443-exec-1]: DirBasedAuthentication: authenticate: before authenticate() call [26/Jul/2016:08:27:27][http-bio-8443-exec-1]: Authenticating UID=john.luk [26/Jul/2016:08:27:27][http-bio-8443-exec-1]: UidPwdDirAuthentication: Authenticating: Searching for uid=john.luk base DN=OU=IT,dc=domain,dc=com [26/Jul/2016:08:27:27][http-bio-8443-exec-1]: Authenticating: User authentication failure: netscape.ldap.LDAPException: error result (1); 000004DC: LdapErr: DSID-0C0906DD, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1772 [26/Jul/2016:08:27:27][http-bio-8443-exec-1]: Authenticating: closing bad connection The directives (bellow) are used to bind the AD2008 and I already tested the account and it is working. auths.instance.UserDirEnrollment.ldap.ldapauth.bindDN=cn=Service Account,ou=IT,dc=domain,dc=com auths.instance.UserDirEnrollment.ldap.ldapauth.bindPWPrompt=password John Luk is applying for the certificate using the web enrollment process (caDirUserCert profile). What am I missing? Thx, sergio -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Wed Jul 27 19:46:42 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 27 Jul 2016 14:46:42 -0500 Subject: [Pki-users] Unknown Certificate Request Type error on enrolling PKCS10 csr in java In-Reply-To: References: Message-ID: <64e09ebf-63fd-8a79-ec91-f06e258a7247@redhat.com> Hi David, We don't have detailed API docs, but you can see how the API is used here: https://git.fedorahosted.org/cgit/pki.git/tree/base/java-tools/src/com/netscape/cmstools/cert/CertRequestSubmitCLI.java The input parameters need to be specified in the corresponding profile inputs, which may differ from one profile to another. I'd suggest you try the CLI first with an XML file to make sure the placements are correct: http://pki.fedoraproject.org/wiki/Submitting_Certificate_Request Then you can try calling it directly through the API. -- Endi S. Dewata On 7/25/2016 3:15 PM, David Kinghorn wrote: > Hey guys, > > I'm trying to upload a csr to the ca in java and am getting a "Unknown > Certificate Request Type" error. There seems to be no documentation on > this. Any help what I'm doing wrong would be great. My code is as follows: > > MultivaluedMap enrollmentRequestMap = new > MultivaluedMapImpl(); > > enrollmentRequestMap.add("cert_request_type", "pkcs10"); > > enrollmentRequestMap.add("cert_request", certData); > > CertEnrollmentRequest enrollmentRequest = new > CertEnrollmentRequest(enrollmentRequestMap); > > enrollmentRequest.setProfileId(config.getRemoteAssetCertProfileId()); > > CertRequestInfos result = client.enrollRequest(enrollmentRequest); > > > Thanks, > ~ David From edewata at redhat.com Wed Jul 27 19:58:47 2016 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 27 Jul 2016 14:58:47 -0500 Subject: [Pki-users] Jar files versions for java pki client In-Reply-To: References: Message-ID: Hi David, That wiki page might be outdated. The client classpath for PKI 10.2.5 is defined in this file: https://git.fedorahosted.org/cgit/pki.git/tree/base/java-tools/bin/pki?h=DOGTAG_10_2_5_BRANCH You would need to find the package that owns each JAR file to find the version number: $ rpm -qf /usr/share/java/commons-cli.jar apache-commons-cli-1.2-13.el7.noarch -- Endi S. Dewata On 7/22/2016 12:35 PM, David Kinghorn wrote: > Hi, > > I'm trying to use the java client in the link below (using nss > authentication), but I'm running into issues finding the right versions > of the various jar files listed. > > http://pki.fedoraproject.org/wiki/Java_Key_Client_API#Setting_up_Buildpath.2FClasspath > > I am getting inundated NoClassDefFoundError, > IncompatibleClassChangeError and the like presumably due to the wrong > version of certain jar files. Is there a guide on which version of the > various files are required? In particular, I'm having an issue with > conflicts between the following two dependencies, but there are probably > more. > > > > javax.ws.rs > > javax.ws.rs-api > > 2.0-m12 > > > > > > org.jboss.resteasy > > resteasy-client > > 3.0.18.Final > > > > > This is on Red Hat Enterprise Linux Server release 7.2 (Maipo) with > jss-4.2.6-37.el7.x86_64 and pki 10.2.5.6 I am using java 7 on tomcat 7 > using maven to build the war file Thanks, ~ David From david at datasages.com Thu Jul 28 21:06:25 2016 From: david at datasages.com (David Kinghorn) Date: Thu, 28 Jul 2016 17:06:25 -0400 Subject: [Pki-users] CertClient.enrollRequest not returning a certId Message-ID: Hey guys, using pki 10.2.5.6 with the java client, I am able to enroll a cert request, but I do not get a cert id or any other meaningful information back. The result.getEntries() collection is empty. Does anyone know what I need to do to have it return the cert id? This is based on the example here: https://git.fedorahosted.org/cgit/pki.git/tree/base/java-tools/src/com/netscape/cmstools/cert/CertRequestSubmitCLI.java The code is below: CertEnrollmentRequest enrollmentRequest = client.getEnrollmentTemplate(config.getRemoteAssetCertProfileId()); for (ProfileInput input : enrollmentRequest.getInputs()) { ProfileAttribute typeAttribute = input.getAttribute("cert_request_type"); if (typeAttribute != null) { typeAttribute.setValue("pkcs10"); } ProfileAttribute requestAttribute = input.getAttribute("cert_request"); if (requestAttribute != null) { requestAttribute.setValue(certData); } } CertRequestInfos result = client.enrollRequest(enrollmentRequest); System.out.println("Entry count: " + result.getEntries().size()); I get an entry count of 0. Thanks, ~ David -------------- next part -------------- An HTML attachment was scrubbed... URL: From chareon at gmail.com Tue Jul 5 05:40:42 2016 From: chareon at gmail.com (Chareon) Date: Tue, 05 Jul 2016 05:40:42 -0000 Subject: [Pki-users] log4j error when creating new user. Message-ID: I'm getting the below error message when attempting to add a new user. Where should I be looking to troubleshoot this issue? root at newca:~# pki -c Secret123 -n caadmin ca-user-add newuser --fullName "New User" log4j:WARN No appenders could be found for logger (org.jboss.resteasy.plugins.providers.DocumentProvider). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. ProcessingException: Unable to invoke request Here is the content of the log4j.properties file in case it helps. # --- BEGIN COPYRIGHT BLOCK --- # Copyright (C) 2012 Red Hat, Inc. # All rights reserved. # Modifications: configuration parameters # --- END COPYRIGHT BLOCK --- log4j.rootLogger=debug, R log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.File=${catalina.base}/logs/catalina.out log4j.appender.R.MaxFileSize=10MB log4j.appender.R.MaxBackupIndex=10 log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n log4j.logger.org.apache.catalina=DEBUG, R log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost]=DEBUG, R log4j.logger.org.apache.catalina.core=DEBUG, R log4j.logger.org.apache.catalina.session=DEBUG, R #resteasy log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.Target=System.out log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p (%c:%L) - %m%n log4j.rootLogger=warn, stdout log4j.rootCategory=debug, stdout log4j.category.org.jboss.resteasy.core=debug log4j.category.org.jboss.resteasy.plugins.providers=debug log4j.category.org.jboss.resteasy.specimpl=debug log4j.category.org.jboss.resteasy.plugins.server=debug log4j.logger.org.jboss.resteasy.mock=debug -------------- next part -------------- An HTML attachment was scrubbed... URL: From chathuranga.gunatillake at gmail.com Mon Jul 11 07:11:21 2016 From: chathuranga.gunatillake at gmail.com (Chathuranga Gunatillake) Date: Mon, 11 Jul 2016 07:11:21 -0000 Subject: [Pki-users] Dog-Tag Automatic Enrolment Message-ID: This question is regarding automation of the certificate enrolment process. The requirement in simple terms would be, 1. CA receives user certificate request (CSR) 2. CA generates certificate 3. Certificate gets delivered to respective user Basically the functions of an RA but remotely. I have looked into SCEP based process. I would like to know, (?) - Any methods of by evading the current shortcomings of SCEP - Any newer technologies / methods that are available - Any suggestions as to how this process could be achieved with a different architecture - Any functions that support this within the current profiles Regards, Chathuranga -------------- next part -------------- An HTML attachment was scrubbed... URL: