From steve at sylvation.com Wed Apr 1 20:37:58 2015 From: steve at sylvation.com (Steve Neuharth) Date: Wed, 1 Apr 2015 15:37:58 -0500 Subject: [Pki-users] Looking for a short path to auto signing server certificates. Message-ID: Hello everyone, I have a requirement to provide a service to our internal linux systems to allow them to self-register and receive a certificate representing the host itself and then a cert representing any application on that host. I have installed DogTag, it's up and running and seems to be working. I'd like to be able to use REST to request a certificate and have it auto-signed. I know that DogTag has a REST interface and while the interface is documented, there are no examples where I can see how it would actually be used to post a CSR, fetch a cert, etc. Normally, I'd just sniff a request made with getcert but as I'm using just dogtag as a standalone install and not as a part of FreeIPA, getcert has no knowledge of my local DogTag CA: *[root at dogtag lib]# getcert list-casCA 'SelfSign': is-default: no ca-type: INTERNAL:SELF next-serial-number: 01CA 'IPA': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/ipa-submitCA 'certmaster': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/certmaster-submitCA 'dogtag-ipa-renew-agent': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/dogtag-ipa-renew-agent-submitCA 'local': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/local-submit* so... how do I make it aware? I'm using fedora21 so I'm at certmonger-0.76.8-1.fc21 and don't have access to the add-ca subtask. It looks like I'd edit files in /var/lib/certmonger/cas but I'm not sure what to add. I apologize in advance for the pedestrian questions. I have read the docs and the getting started guide and while they provide examples for self-signed certs and for using FreeIPA, I don't see much info on using getcert with DogTag as a standalone product. I'd also like to explore using SCEP for requesting certs from our MS PKI. Is there a guide or info setting up certmonger/getcert to hit a SCEP URL? Thanks for your continued work on DogTag and certmonger. They ROCK and will solve big problems for my client if I can just get them to work the way I need them to. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From nalin at redhat.com Wed Apr 1 21:43:08 2015 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 1 Apr 2015 17:43:08 -0400 Subject: [Pki-users] Looking for a short path to auto signing server certificates. In-Reply-To: References: Message-ID: <20150401214308.GD1672@redhat.com> On Wed, Apr 01, 2015 at 03:37:58PM -0500, Steve Neuharth wrote: > Hello everyone, > > I have a requirement to provide a service to our internal linux systems to > allow them to self-register and receive a certificate representing the host > itself and then a cert representing any application on that host. I have > installed DogTag, it's up and running and seems to be working. > > I'd like to be able to use REST to request a certificate and have it > auto-signed. I know that DogTag has a REST interface and while the > interface is documented, there are no examples where I can see how it would > actually be used to post a CSR, fetch a cert, etc. > > Normally, I'd just sniff a request made with getcert but as I'm using just > dogtag as a standalone install and not as a part of FreeIPA, getcert has no > knowledge of my local DogTag CA: > > *[root at dogtag lib]# getcert list-casCA 'SelfSign': is-default: > no ca-type: INTERNAL:SELF next-serial-number: 01CA > 'IPA': is-default: no ca-type: EXTERNAL > helper-location: /usr/libexec/certmonger/ipa-submitCA 'certmaster': > is-default: no ca-type: EXTERNAL helper-location: > /usr/libexec/certmonger/certmaster-submitCA > 'dogtag-ipa-renew-agent': is-default: no ca-type: > EXTERNAL helper-location: > /usr/libexec/certmonger/dogtag-ipa-renew-agent-submitCA 'local': > is-default: no ca-type: EXTERNAL helper-location: > /usr/libexec/certmonger/local-submit* > > so... how do I make it aware? I'm using fedora21 so I'm at > certmonger-0.76.8-1.fc21 and don't have access to the add-ca subtask. It > looks like I'd edit files in /var/lib/certmonger/cas but I'm not sure what > to add. If you're after something you can use to poke at the server from the command line, the 'pki' tool from the 'pki-tools' package may be closer to what you're looking for. If not, well, here's more than you probably want to know. The CAs which certmonger knows about by default are the ones that don't require any additional configuration to be passed to them. For example, the ipa-submit helper can dig up all of the configuration that it needs from the IPA configuration files. Along similar lines, the dogtag-ipa-renew-agent-submit helper can dig through IPA's configuration for some settings, and have hardwired defaults for the rest. The general-purpose dogtag-submit helper doesn't have that expectation, and it hasn't seen much use yet, so you may find some bugs (well, more than usual). Anyway, a new file telling certmonger how to invoke it would look something like this: id=Dogtag ca_type=EXTERNAL ca_external_helper=/usr/libexec/certmonger/dogtag-submit ... The flags that would be passed to the dogtag-submit helper depend on whether or not it's expected to use agent creds to use Dogtag's agent services to approve the signing requests that it submits. Briefly: -T caServerCert The name of the Dogtag enrollment profile to use. -E http://server:8080/ca/ee/ca The location of Dogtag's end-user service. -A https://server:8443/ca/agent/ca The location of Dogtag's agent services, if agent creds will be used. -d /etc/httpd/alias -n ipaCert -p /etc/httpd/alias/pwdfile.txt The location of the agent creds, if agent creds will be used. Some words of caution: the helper doesn't use the new REST API, but rather the old forms-based one, due to a combination of wanting to remain compatible with older versions of Dogtag and wanting to avoid adding new dependencies to the server via the REST API. If you try to use agent creds to auto-approve things, but the enrollment profile doesn't provide defaults for every extension value that it populates, the logic in dogtag-submit that tries to use agent creds to approve requests won't be able to tell the server to just use the defaults, and things could go awry. The -O flag may help here. You may want to run dogtag-submit interactively to get the flags sorted out, passing in previous output using the -S flag to mimic the certmonger daemon running it iteratively. > I apologize in advance for the pedestrian questions. I have read the docs > and the getting started guide and while they provide examples for > self-signed certs and for using FreeIPA, I don't see much info on using > getcert with DogTag as a standalone product. I'd also like to explore using > SCEP for requesting certs from our MS PKI. Is there a guide or info setting > up certmonger/getcert to hit a SCEP URL? That functionality was new in 0.77, and I've just submitted a candidate update build for F21, so hopefully some will be available in the updates-testing tree this week. Anyway, the short version of how to use an SCEP server is: * Use "getcert add-scep-ca -u $URL -c $NAME" to point the service at your SCEP server's URL and give the CA a nickname. * If it's an HTTPS URL, use the -R flag to point it to a PEM-formatted copy of the CA's certificate. If not, use "getcert list" and "getcert list-cas" to display request and certificate fingerprints for manual verification. * Use "getcert -c $NAME" to request a certificate. * Use the -L or -l flag to supply the enrollment PIN or point to a file that contains the enrollment PIN. A lot of the logic for supporting SCEP is new, so if you run into problems in that area, please make sure to let us know. HTH, Nalin From steve at sylvation.com Fri Apr 3 20:47:43 2015 From: steve at sylvation.com (Steve Neuharth) Date: Fri, 3 Apr 2015 15:47:43 -0500 Subject: [Pki-users] Looking for a short path to auto signing server certificates. In-Reply-To: <20150401214308.GD1672@redhat.com> References: <20150401214308.GD1672@redhat.com> Message-ID: Thanks again for the information. I have a couple more questions for you. first is that I have added a new 'Dogtag' ca in /var/lib/certmonger/cas/20150331194831-5 *id=Dogtagca_aka=Dogtag PKIca_is_default=0ca_type=EXTERNALca_external_helper=/usr/libexec/certmonger/dogtag-submitca_required_enroll_attributes=template-subjectca_required_renewal_attributes=template-subject* however, when I run getcert list-cas, it does not appear The next question is regarding the dogtag-submit helper itself. I'm trying to execute this: */usr/libexec/certmonger/dogtag-submit -vv -c ~/test.crt -k ~/test.key -E https://dogtag.test.org:8443/ca/ee/ca -A https://dogtag.test.org:8443/ca/agent/ca -T caServerCert -d /etc/httpd/alias -n caadmin -p /etc/pki/pki-tomcat/alias/pwdfile.txt -C /etc/pki/pki-tomcat/alias* and then I paste in my csr and hit 'ctrl-d' and I get: *code = 77code_text = "Problem with the SSL CA cert (path? access rights?)"results = "(null)"Error 77 connecting to https://dogtag.test.org:8443/ca/ee/ca/profileSubmit : Problem with the SSL CA cert (path? access rights?).* I guess I'm not sure what CA cert path it's talking about. I've tried the pki-tomcat alias path and I've tried pointing to the CAcert that I downloaded from the WebUI on the 'Import CA Certificate Chain' page but I always get the same error. Thanks for your help, --steve On Wed, Apr 1, 2015 at 4:43 PM, Nalin Dahyabhai wrote: > On Wed, Apr 01, 2015 at 03:37:58PM -0500, Steve Neuharth wrote: > > Hello everyone, > > > > I have a requirement to provide a service to our internal linux systems > to > > allow them to self-register and receive a certificate representing the > host > > itself and then a cert representing any application on that host. I have > > installed DogTag, it's up and running and seems to be working. > > > > I'd like to be able to use REST to request a certificate and have it > > auto-signed. I know that DogTag has a REST interface and while the > > interface is documented, there are no examples where I can see how it > would > > actually be used to post a CSR, fetch a cert, etc. > > > > Normally, I'd just sniff a request made with getcert but as I'm using > just > > dogtag as a standalone install and not as a part of FreeIPA, getcert has > no > > knowledge of my local DogTag CA: > > > > *[root at dogtag lib]# getcert list-casCA 'SelfSign': is-default: > > no ca-type: INTERNAL:SELF next-serial-number: 01CA > > 'IPA': is-default: no ca-type: EXTERNAL > > helper-location: /usr/libexec/certmonger/ipa-submitCA 'certmaster': > > is-default: no ca-type: EXTERNAL helper-location: > > /usr/libexec/certmonger/certmaster-submitCA > > 'dogtag-ipa-renew-agent': is-default: no ca-type: > > EXTERNAL helper-location: > > /usr/libexec/certmonger/dogtag-ipa-renew-agent-submitCA 'local': > > is-default: no ca-type: EXTERNAL helper-location: > > /usr/libexec/certmonger/local-submit* > > > > so... how do I make it aware? I'm using fedora21 so I'm at > > certmonger-0.76.8-1.fc21 and don't have access to the add-ca subtask. It > > looks like I'd edit files in /var/lib/certmonger/cas but I'm not sure > what > > to add. > > If you're after something you can use to poke at the server from the > command line, the 'pki' tool from the 'pki-tools' package may be closer > to what you're looking for. > > If not, well, here's more than you probably want to know. > > The CAs which certmonger knows about by default are the ones that don't > require any additional configuration to be passed to them. For example, > the ipa-submit helper can dig up all of the configuration that it needs > from the IPA configuration files. Along similar lines, the > dogtag-ipa-renew-agent-submit helper can dig through IPA's configuration > for some settings, and have hardwired defaults for the rest. > > The general-purpose dogtag-submit helper doesn't have that expectation, > and it hasn't seen much use yet, so you may find some bugs (well, more > than usual). Anyway, a new file telling certmonger how to invoke it > would look something like this: > > id=Dogtag > ca_type=EXTERNAL > ca_external_helper=/usr/libexec/certmonger/dogtag-submit ... > > The flags that would be passed to the dogtag-submit helper depend on > whether or not it's expected to use agent creds to use Dogtag's agent > services to approve the signing requests that it submits. Briefly: > -T caServerCert > The name of the Dogtag enrollment profile to use. > -E http://server:8080/ca/ee/ca > The location of Dogtag's end-user service. > -A https://server:8443/ca/agent/ca > The location of Dogtag's agent services, if agent creds will be used. > -d /etc/httpd/alias -n ipaCert -p /etc/httpd/alias/pwdfile.txt > The location of the agent creds, if agent creds will be used. > > Some words of caution: the helper doesn't use the new REST API, but > rather the old forms-based one, due to a combination of wanting to > remain compatible with older versions of Dogtag and wanting to avoid > adding new dependencies to the server via the REST API. > > If you try to use agent creds to auto-approve things, but the enrollment > profile doesn't provide defaults for every extension value that it > populates, the logic in dogtag-submit that tries to use agent creds to > approve requests won't be able to tell the server to just use the > defaults, and things could go awry. The -O flag may help here. > > You may want to run dogtag-submit interactively to get the flags sorted > out, passing in previous output using the -S flag to mimic the > certmonger daemon running it iteratively. > > > I apologize in advance for the pedestrian questions. I have read the docs > > and the getting started guide and while they provide examples for > > self-signed certs and for using FreeIPA, I don't see much info on using > > getcert with DogTag as a standalone product. I'd also like to explore > using > > SCEP for requesting certs from our MS PKI. Is there a guide or info > setting > > up certmonger/getcert to hit a SCEP URL? > > That functionality was new in 0.77, and I've just submitted a candidate > update build for F21, so hopefully some will be available in the > updates-testing tree this week. Anyway, the short version of how to use > an SCEP server is: > > * Use "getcert add-scep-ca -u $URL -c $NAME" to point the service at > your SCEP server's URL and give the CA a nickname. > * If it's an HTTPS URL, use the -R flag to point it to a PEM-formatted > copy of the CA's certificate. If not, use "getcert list" and > "getcert list-cas" to display request and certificate fingerprints > for manual verification. > * Use "getcert -c $NAME" to request a certificate. > * Use the -L or -l flag to supply the enrollment PIN or point to a > file that contains the enrollment PIN. > > A lot of the logic for supporting SCEP is new, so if you run into > problems in that area, please make sure to let us know. > > HTH, > > Nalin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at sylvation.com Fri Apr 3 21:07:08 2015 From: steve at sylvation.com (Steve Neuharth) Date: Fri, 3 Apr 2015 16:07:08 -0500 Subject: [Pki-users] Looking for a short path to auto signing server certificates. In-Reply-To: References: <20150401214308.GD1672@redhat.com> Message-ID: I should add too that *curl --cacert ca.crt https://dogtag.test.org:8443/ca/services *does get a valid response while using that file with the -C switch on dogtag-submit does not. On Fri, Apr 3, 2015 at 3:47 PM, Steve Neuharth wrote: > Thanks again for the information. I have a couple more questions for you. > > first is that I have added a new 'Dogtag' ca in > /var/lib/certmonger/cas/20150331194831-5 > > > > > > > > > *id=Dogtagca_aka=Dogtag > PKIca_is_default=0ca_type=EXTERNALca_external_helper=/usr/libexec/certmonger/dogtag-submitca_required_enroll_attributes=template-subjectca_required_renewal_attributes=template-subject* > > however, when I run getcert list-cas, it does not appear > > The next question is regarding the dogtag-submit helper itself. I'm trying > to execute this: > > */usr/libexec/certmonger/dogtag-submit -vv -c ~/test.crt -k ~/test.key -E > https://dogtag.test.org:8443/ca/ee/ca > -A > https://dogtag.test.org:8443/ca/agent/ca > -T caServerCert -d > /etc/httpd/alias -n caadmin -p /etc/pki/pki-tomcat/alias/pwdfile.txt -C > /etc/pki/pki-tomcat/alias* > > and then I paste in my csr and hit 'ctrl-d' and I get: > > > > > > > *code = 77code_text = "Problem with the SSL CA cert (path? access > rights?)"results = "(null)"Error 77 connecting to > https://dogtag.test.org:8443/ca/ee/ca/profileSubmit > : Problem with the SSL > CA cert (path? access rights?).* > I guess I'm not sure what CA cert path it's talking about. I've tried the > pki-tomcat alias path and I've tried pointing to the CAcert that I > downloaded from the WebUI on the 'Import CA Certificate Chain' page but I > always get the same error. > > Thanks for your help, > --steve > > On Wed, Apr 1, 2015 at 4:43 PM, Nalin Dahyabhai wrote: > >> On Wed, Apr 01, 2015 at 03:37:58PM -0500, Steve Neuharth wrote: >> > Hello everyone, >> > >> > I have a requirement to provide a service to our internal linux systems >> to >> > allow them to self-register and receive a certificate representing the >> host >> > itself and then a cert representing any application on that host. I have >> > installed DogTag, it's up and running and seems to be working. >> > >> > I'd like to be able to use REST to request a certificate and have it >> > auto-signed. I know that DogTag has a REST interface and while the >> > interface is documented, there are no examples where I can see how it >> would >> > actually be used to post a CSR, fetch a cert, etc. >> > >> > Normally, I'd just sniff a request made with getcert but as I'm using >> just >> > dogtag as a standalone install and not as a part of FreeIPA, getcert >> has no >> > knowledge of my local DogTag CA: >> > >> > *[root at dogtag lib]# getcert list-casCA 'SelfSign': is-default: >> > no ca-type: INTERNAL:SELF next-serial-number: 01CA >> > 'IPA': is-default: no ca-type: EXTERNAL >> > helper-location: /usr/libexec/certmonger/ipa-submitCA 'certmaster': >> > is-default: no ca-type: EXTERNAL helper-location: >> > /usr/libexec/certmonger/certmaster-submitCA >> > 'dogtag-ipa-renew-agent': is-default: no ca-type: >> > EXTERNAL helper-location: >> > /usr/libexec/certmonger/dogtag-ipa-renew-agent-submitCA 'local': >> > is-default: no ca-type: EXTERNAL helper-location: >> > /usr/libexec/certmonger/local-submit* >> > >> > so... how do I make it aware? I'm using fedora21 so I'm at >> > certmonger-0.76.8-1.fc21 and don't have access to the add-ca subtask. It >> > looks like I'd edit files in /var/lib/certmonger/cas but I'm not sure >> what >> > to add. >> >> If you're after something you can use to poke at the server from the >> command line, the 'pki' tool from the 'pki-tools' package may be closer >> to what you're looking for. >> >> If not, well, here's more than you probably want to know. >> >> The CAs which certmonger knows about by default are the ones that don't >> require any additional configuration to be passed to them. For example, >> the ipa-submit helper can dig up all of the configuration that it needs >> from the IPA configuration files. Along similar lines, the >> dogtag-ipa-renew-agent-submit helper can dig through IPA's configuration >> for some settings, and have hardwired defaults for the rest. >> >> The general-purpose dogtag-submit helper doesn't have that expectation, >> and it hasn't seen much use yet, so you may find some bugs (well, more >> than usual). Anyway, a new file telling certmonger how to invoke it >> would look something like this: >> >> id=Dogtag >> ca_type=EXTERNAL >> ca_external_helper=/usr/libexec/certmonger/dogtag-submit ... >> >> The flags that would be passed to the dogtag-submit helper depend on >> whether or not it's expected to use agent creds to use Dogtag's agent >> services to approve the signing requests that it submits. Briefly: >> -T caServerCert >> The name of the Dogtag enrollment profile to use. >> -E http://server:8080/ca/ee/ca >> The location of Dogtag's end-user service. >> -A https://server:8443/ca/agent/ca >> The location of Dogtag's agent services, if agent creds will be used. >> -d /etc/httpd/alias -n ipaCert -p /etc/httpd/alias/pwdfile.txt >> The location of the agent creds, if agent creds will be used. >> >> Some words of caution: the helper doesn't use the new REST API, but >> rather the old forms-based one, due to a combination of wanting to >> remain compatible with older versions of Dogtag and wanting to avoid >> adding new dependencies to the server via the REST API. >> >> If you try to use agent creds to auto-approve things, but the enrollment >> profile doesn't provide defaults for every extension value that it >> populates, the logic in dogtag-submit that tries to use agent creds to >> approve requests won't be able to tell the server to just use the >> defaults, and things could go awry. The -O flag may help here. >> >> You may want to run dogtag-submit interactively to get the flags sorted >> out, passing in previous output using the -S flag to mimic the >> certmonger daemon running it iteratively. >> >> > I apologize in advance for the pedestrian questions. I have read the >> docs >> > and the getting started guide and while they provide examples for >> > self-signed certs and for using FreeIPA, I don't see much info on using >> > getcert with DogTag as a standalone product. I'd also like to explore >> using >> > SCEP for requesting certs from our MS PKI. Is there a guide or info >> setting >> > up certmonger/getcert to hit a SCEP URL? >> >> That functionality was new in 0.77, and I've just submitted a candidate >> update build for F21, so hopefully some will be available in the >> updates-testing tree this week. Anyway, the short version of how to use >> an SCEP server is: >> >> * Use "getcert add-scep-ca -u $URL -c $NAME" to point the service at >> your SCEP server's URL and give the CA a nickname. >> * If it's an HTTPS URL, use the -R flag to point it to a PEM-formatted >> copy of the CA's certificate. If not, use "getcert list" and >> "getcert list-cas" to display request and certificate fingerprints >> for manual verification. >> * Use "getcert -c $NAME" to request a certificate. >> * Use the -L or -l flag to supply the enrollment PIN or point to a >> file that contains the enrollment PIN. >> >> A lot of the logic for supporting SCEP is new, so if you run into >> problems in that area, please make sure to let us know. >> >> HTH, >> >> Nalin >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at sylvation.com Sat Apr 4 14:36:33 2015 From: steve at sylvation.com (Steve Neuharth) Date: Sat, 4 Apr 2015 09:36:33 -0500 Subject: [Pki-users] trying to use cert authentication in curl for cert requests. Message-ID: I'm trying to use certmonger's dogtag-submit helper like this: */usr/libexec/certmonger/dogtag-submit -vv -E https://dogtag.test.org:8443/ca/ee/ca -A https://dogtag.test.org:8443/ca/agent/ca -T caAgentServerCert -i /root/ca.crt -c /root/test/cert.pem -k /root/test/key.pem foo.csr.pem* I can perform the same GET (from the debug results from dogtag-submit) using curl with the same cert.pem and key.pem and the request returns a valid response. What am I doing wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at sylvation.com Sat Apr 4 18:53:04 2015 From: steve at sylvation.com (Steve Neuharth) Date: Sat, 4 Apr 2015 13:53:04 -0500 Subject: [Pki-users] getting NEED_TO_NOTIFY_ISSUED_SAVE_FAILED with dogtag-submit Message-ID: Hello, I'm using the following configuration with certmonger: *id=Dogtagca_aka=Dogtag (certmonger 0.76.8)ca_is_default=0ca_type=EXTERNALca_external_helper=/usr/libexec/certmonger/dogtag-submit -E https://dogtag.test.org:8443/ca/ee/ca -A https://dogtag.test.org:8443/ca/agent/ca -i /root/ca.crt* I'm able to submit a request like this: *getcert request -k /tmp/getcert.key -f /tmp/getcert.crt -c Dogtag -D foo.bar.org * but after I refresh the cert requests, it's in NEED_TO_NOTIFY_ISSUED_SAVE_FAILED status and occasionally shows START_SAVING_CERT status. *Request ID '20150403093236': status: NEED_TO_NOTIFY_ISSUED_SAVE_FAILED stuck: no key pair storage: type=FILE,location='/tmp/getcert.key' certificate: type=FILE,location='/tmp/getcert.crt' CA: Dogtag issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes* selinux is set to 'permissive' and the perms on /tmp are 777. I cant thonk of any other reason it would fail to save the cert. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at sylvation.com Sat Apr 4 19:17:03 2015 From: steve at sylvation.com (Steve Neuharth) Date: Sat, 4 Apr 2015 14:17:03 -0500 Subject: [Pki-users] Looking for a short path to auto signing server certificates. In-Reply-To: References: <20150401214308.GD1672@redhat.com> Message-ID: I see the issue now... I should have used -i instead of -C. I was also able to add my new ca, Dogtag but i had to stop certmonger, add the ca and then start certmonger again. On Fri, Apr 3, 2015 at 4:07 PM, Steve Neuharth wrote: > I should add too that *curl --cacert ca.crt > https://dogtag.test.org:8443/ca/services > *does get a valid response > while using that file with the -C switch on dogtag-submit does not. > > On Fri, Apr 3, 2015 at 3:47 PM, Steve Neuharth > wrote: > >> Thanks again for the information. I have a couple more questions for you. >> >> first is that I have added a new 'Dogtag' ca in >> /var/lib/certmonger/cas/20150331194831-5 >> >> >> >> >> >> >> >> >> *id=Dogtagca_aka=Dogtag >> PKIca_is_default=0ca_type=EXTERNALca_external_helper=/usr/libexec/certmonger/dogtag-submitca_required_enroll_attributes=template-subjectca_required_renewal_attributes=template-subject* >> >> however, when I run getcert list-cas, it does not appear >> >> The next question is regarding the dogtag-submit helper itself. I'm >> trying to execute this: >> >> */usr/libexec/certmonger/dogtag-submit -vv -c ~/test.crt -k ~/test.key -E >> https://dogtag.test.org:8443/ca/ee/ca >> -A >> https://dogtag.test.org:8443/ca/agent/ca >> -T caServerCert -d >> /etc/httpd/alias -n caadmin -p /etc/pki/pki-tomcat/alias/pwdfile.txt -C >> /etc/pki/pki-tomcat/alias* >> >> and then I paste in my csr and hit 'ctrl-d' and I get: >> >> >> >> >> >> >> *code = 77code_text = "Problem with the SSL CA cert (path? access >> rights?)"results = "(null)"Error 77 connecting to >> https://dogtag.test.org:8443/ca/ee/ca/profileSubmit >> : Problem with the SSL >> CA cert (path? access rights?).* >> I guess I'm not sure what CA cert path it's talking about. I've tried the >> pki-tomcat alias path and I've tried pointing to the CAcert that I >> downloaded from the WebUI on the 'Import CA Certificate Chain' page but >> I always get the same error. >> >> Thanks for your help, >> --steve >> >> On Wed, Apr 1, 2015 at 4:43 PM, Nalin Dahyabhai wrote: >> >>> On Wed, Apr 01, 2015 at 03:37:58PM -0500, Steve Neuharth wrote: >>> > Hello everyone, >>> > >>> > I have a requirement to provide a service to our internal linux >>> systems to >>> > allow them to self-register and receive a certificate representing the >>> host >>> > itself and then a cert representing any application on that host. I >>> have >>> > installed DogTag, it's up and running and seems to be working. >>> > >>> > I'd like to be able to use REST to request a certificate and have it >>> > auto-signed. I know that DogTag has a REST interface and while the >>> > interface is documented, there are no examples where I can see how it >>> would >>> > actually be used to post a CSR, fetch a cert, etc. >>> > >>> > Normally, I'd just sniff a request made with getcert but as I'm using >>> just >>> > dogtag as a standalone install and not as a part of FreeIPA, getcert >>> has no >>> > knowledge of my local DogTag CA: >>> > >>> > *[root at dogtag lib]# getcert list-casCA 'SelfSign': is-default: >>> > no ca-type: INTERNAL:SELF next-serial-number: 01CA >>> > 'IPA': is-default: no ca-type: EXTERNAL >>> > helper-location: /usr/libexec/certmonger/ipa-submitCA 'certmaster': >>> > is-default: no ca-type: EXTERNAL helper-location: >>> > /usr/libexec/certmonger/certmaster-submitCA >>> > 'dogtag-ipa-renew-agent': is-default: no ca-type: >>> > EXTERNAL helper-location: >>> > /usr/libexec/certmonger/dogtag-ipa-renew-agent-submitCA 'local': >>> > is-default: no ca-type: EXTERNAL helper-location: >>> > /usr/libexec/certmonger/local-submit* >>> > >>> > so... how do I make it aware? I'm using fedora21 so I'm at >>> > certmonger-0.76.8-1.fc21 and don't have access to the add-ca subtask. >>> It >>> > looks like I'd edit files in /var/lib/certmonger/cas but I'm not sure >>> what >>> > to add. >>> >>> If you're after something you can use to poke at the server from the >>> command line, the 'pki' tool from the 'pki-tools' package may be closer >>> to what you're looking for. >>> >>> If not, well, here's more than you probably want to know. >>> >>> The CAs which certmonger knows about by default are the ones that don't >>> require any additional configuration to be passed to them. For example, >>> the ipa-submit helper can dig up all of the configuration that it needs >>> from the IPA configuration files. Along similar lines, the >>> dogtag-ipa-renew-agent-submit helper can dig through IPA's configuration >>> for some settings, and have hardwired defaults for the rest. >>> >>> The general-purpose dogtag-submit helper doesn't have that expectation, >>> and it hasn't seen much use yet, so you may find some bugs (well, more >>> than usual). Anyway, a new file telling certmonger how to invoke it >>> would look something like this: >>> >>> id=Dogtag >>> ca_type=EXTERNAL >>> ca_external_helper=/usr/libexec/certmonger/dogtag-submit ... >>> >>> The flags that would be passed to the dogtag-submit helper depend on >>> whether or not it's expected to use agent creds to use Dogtag's agent >>> services to approve the signing requests that it submits. Briefly: >>> -T caServerCert >>> The name of the Dogtag enrollment profile to use. >>> -E http://server:8080/ca/ee/ca >>> The location of Dogtag's end-user service. >>> -A https://server:8443/ca/agent/ca >>> The location of Dogtag's agent services, if agent creds will be used. >>> -d /etc/httpd/alias -n ipaCert -p /etc/httpd/alias/pwdfile.txt >>> The location of the agent creds, if agent creds will be used. >>> >>> Some words of caution: the helper doesn't use the new REST API, but >>> rather the old forms-based one, due to a combination of wanting to >>> remain compatible with older versions of Dogtag and wanting to avoid >>> adding new dependencies to the server via the REST API. >>> >>> If you try to use agent creds to auto-approve things, but the enrollment >>> profile doesn't provide defaults for every extension value that it >>> populates, the logic in dogtag-submit that tries to use agent creds to >>> approve requests won't be able to tell the server to just use the >>> defaults, and things could go awry. The -O flag may help here. >>> >>> You may want to run dogtag-submit interactively to get the flags sorted >>> out, passing in previous output using the -S flag to mimic the >>> certmonger daemon running it iteratively. >>> >>> > I apologize in advance for the pedestrian questions. I have read the >>> docs >>> > and the getting started guide and while they provide examples for >>> > self-signed certs and for using FreeIPA, I don't see much info on using >>> > getcert with DogTag as a standalone product. I'd also like to explore >>> using >>> > SCEP for requesting certs from our MS PKI. Is there a guide or info >>> setting >>> > up certmonger/getcert to hit a SCEP URL? >>> >>> That functionality was new in 0.77, and I've just submitted a candidate >>> update build for F21, so hopefully some will be available in the >>> updates-testing tree this week. Anyway, the short version of how to use >>> an SCEP server is: >>> >>> * Use "getcert add-scep-ca -u $URL -c $NAME" to point the service at >>> your SCEP server's URL and give the CA a nickname. >>> * If it's an HTTPS URL, use the -R flag to point it to a PEM-formatted >>> copy of the CA's certificate. If not, use "getcert list" and >>> "getcert list-cas" to display request and certificate fingerprints >>> for manual verification. >>> * Use "getcert -c $NAME" to request a certificate. >>> * Use the -L or -l flag to supply the enrollment PIN or point to a >>> file that contains the enrollment PIN. >>> >>> A lot of the logic for supporting SCEP is new, so if you run into >>> problems in that area, please make sure to let us know. >>> >>> HTH, >>> >>> Nalin >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at sylvation.com Sat Apr 4 20:35:08 2015 From: steve at sylvation.com (Steve Neuharth) Date: Sat, 4 Apr 2015 15:35:08 -0500 Subject: [Pki-users] getting NEED_TO_NOTIFY_ISSUED_SAVE_FAILED with dogtag-submit In-Reply-To: References: Message-ID: hmmm. strange. I see that the cert is indeed being fetched and put into the request file in /var/lib/certmonger/requests. Why isn't it making it to the final destination in /tmp/getcert.crt? Verbose logging also tells me nothing about why it's not working but I do see this in /var/log/messages: *Apr 3 06:14:36 dogtag certmonger: Certificate in file "/tmp/getcert.crt" issued by CA but not saved.* ideas? On Sat, Apr 4, 2015 at 1:53 PM, Steve Neuharth wrote: > Hello, > > I'm using the following configuration with certmonger: > > > > > > > > *id=Dogtagca_aka=Dogtag (certmonger > 0.76.8)ca_is_default=0ca_type=EXTERNALca_external_helper=/usr/libexec/certmonger/dogtag-submit > -E https://dogtag.test.org:8443/ca/ee/ca > -A > https://dogtag.test.org:8443/ca/agent/ca > -i /root/ca.crt* > I'm able to submit a request like this: > > > *getcert request -k /tmp/getcert.key -f /tmp/getcert.crt -c Dogtag -D > foo.bar.org * > but after I refresh the cert requests, it's in > NEED_TO_NOTIFY_ISSUED_SAVE_FAILED status and occasionally shows > START_SAVING_CERT status. > > > > > > > > > > > > > > > *Request ID '20150403093236': status: > NEED_TO_NOTIFY_ISSUED_SAVE_FAILED stuck: no key pair storage: > type=FILE,location='/tmp/getcert.key' certificate: > type=FILE,location='/tmp/getcert.crt' CA: Dogtag > issuer: subject: expires: unknown pre-save > command: post-save command: track: yes auto-renew: yes* > selinux is set to 'permissive' and the perms on /tmp are 777. I cant thonk > of any other reason it would fail to save the cert. > > --steve > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgallartm at gmail.com Mon Apr 6 13:32:43 2015 From: jgallartm at gmail.com (Javier Gallart) Date: Mon, 6 Apr 2015 15:32:43 +0200 Subject: [Pki-users] EMV CPS 1.1 support Message-ID: Hello we're working with G&D SmartCafe 3.2 cards and trying to integrate them with Dogtag. They use the EMV CPS 1.1 key derivation protocol for obtaining the session keys in a Secure Channel establishment (SCP02). Is the any plan to include it in Dogtag?. If not, would a patch implementing it be considered? Thanks in advance Javi -------------- next part -------------- An HTML attachment was scrubbed... URL: From nalin at redhat.com Tue Apr 7 14:25:23 2015 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 7 Apr 2015 10:25:23 -0400 Subject: [Pki-users] getting NEED_TO_NOTIFY_ISSUED_SAVE_FAILED with dogtag-submit In-Reply-To: References: Message-ID: <20150407142523.GD26921@redhat.com> On Sat, Apr 04, 2015 at 03:35:08PM -0500, Steve Neuharth wrote: > hmmm. strange. I see that the cert is indeed being fetched and put into the > request file in /var/lib/certmonger/requests. Why isn't it making it to the > final destination in /tmp/getcert.crt? > > Verbose logging also tells me nothing about why it's not working but I do > see this in /var/log/messages: > > > *Apr 3 06:14:36 dogtag certmonger: Certificate in file "/tmp/getcert.crt" > issued by CA but not saved.* > ideas? Check if the data coming back from the server has extra "noise" in front of or after it -- or a blank line somewhere in between -- when it's recorded in the request file in /var/lib/certmonger/requests. The logic for saving to a file can get tripped up by that sort of problem, and it doesn't crop up until we get to that step. One of the things that happened as part of the SCEP work was that the output from the helper is now cleaned up much more thoroughly by the daemon before it's saved to its request file, so 0.77 won't have that problem. If that isn't the cause, running the daemon directly with its debugging flags (I tend to use -d3 most often) should hopefully turn up some details on what the cause of the error is. HTH, Nalin From steve at sylvation.com Tue Apr 7 17:18:24 2015 From: steve at sylvation.com (Steve Neuharth) Date: Tue, 7 Apr 2015 12:18:24 -0500 Subject: [Pki-users] getting NEED_TO_NOTIFY_ISSUED_SAVE_FAILED with dogtag-submit In-Reply-To: <20150407142523.GD26921@redhat.com> References: <20150407142523.GD26921@redhat.com> Message-ID: yes, the certificate in the request file has a newline after the certificate data: cert=-----BEGIN CERTIFICATE----- MIIDajCCAlKgAwIBAgIBIDANBgkqhkiG9w0BAQsFADBEMSEwHwYDVQQKDBh0ZXN0 ...cert data... lRCw27w7Yw/JUMqJYoE= <---- extra newline -----END CERTIFICATE----- Looks like that's the problem. When I make a similar request using cURL, I don't get the '\n' in the xml so it must be an error in parsing the xml response inside dogtag-submit. I've also tried the v77.1-1 rpm from rawhide and I get the same behavior. Hmmmm. I see in line 469 of certread-n.c, it's checking for a newline and adding one if there isn't one already there. It looks like that logic is not functioning correctly. I don't get a '\n' in the xml response from curl so I'm not sure why it would be adding another one. Please let me know if there's anything I can do to help debug this. I have verified the problem by shutting down certmonger, removing the newline and starting it again. After the restart, the cert was processed as expected. --steve On Tue, Apr 7, 2015 at 9:25 AM, Nalin Dahyabhai wrote: > On Sat, Apr 04, 2015 at 03:35:08PM -0500, Steve Neuharth wrote: > > hmmm. strange. I see that the cert is indeed being fetched and put into > the > > request file in /var/lib/certmonger/requests. Why isn't it making it to > the > > final destination in /tmp/getcert.crt? > > > > Verbose logging also tells me nothing about why it's not working but I do > > see this in /var/log/messages: > > > > > > *Apr 3 06:14:36 dogtag certmonger: Certificate in file > "/tmp/getcert.crt" > > issued by CA but not saved.* > > ideas? > > Check if the data coming back from the server has extra "noise" in front > of or after it -- or a blank line somewhere in between -- when it's > recorded in the request file in /var/lib/certmonger/requests. The logic > for saving to a file can get tripped up by that sort of problem, and it > doesn't crop up until we get to that step. > > One of the things that happened as part of the SCEP work was that the > output from the helper is now cleaned up much more thoroughly by the > daemon before it's saved to its request file, so 0.77 won't have that > problem. > > If that isn't the cause, running the daemon directly with its debugging > flags (I tend to use -d3 most often) should hopefully turn up some > details on what the cause of the error is. > > HTH, > > Nalin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nalin at redhat.com Tue Apr 7 17:56:19 2015 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 7 Apr 2015 13:56:19 -0400 Subject: [Pki-users] getting NEED_TO_NOTIFY_ISSUED_SAVE_FAILED with dogtag-submit In-Reply-To: References: <20150407142523.GD26921@redhat.com> Message-ID: <20150407175619.GI26921@redhat.com> On Tue, Apr 07, 2015 at 12:18:24PM -0500, Steve Neuharth wrote: > yes, the certificate in the request file has a newline after the > certificate data: > > cert=-----BEGIN CERTIFICATE----- > MIIDajCCAlKgAwIBAgIBIDANBgkqhkiG9w0BAQsFADBEMSEwHwYDVQQKDBh0ZXN0 > ...cert data... > lRCw27w7Yw/JUMqJYoE= > <---- extra newline > -----END CERTIFICATE----- > > > Looks like that's the problem. When I make a similar request using cURL, I > don't get the '\n' in the xml so it must be an error in parsing the xml > response inside dogtag-submit. I've also tried the v77.1-1 rpm from rawhide > and I get the same behavior. Hmm, I'm testing with 0.77.1 and pki-ca-9.0.3-38.el6_6 (you're on Fedora IIRC, so it's not exactly the same, but I don't have an F21 box handy ATM), and the data's getting cleaned before it's saved there. Did you start with an older version and update after dogtag-submit had finished its work? The newer daemon wouldn't have been in a position to clean up the data it got from the helper in that case. Nalin From steve at sylvation.com Tue Apr 7 18:58:24 2015 From: steve at sylvation.com (Steve Neuharth) Date: Tue, 7 Apr 2015 13:58:24 -0500 Subject: [Pki-users] getting NEED_TO_NOTIFY_ISSUED_SAVE_FAILED with dogtag-submit In-Reply-To: <20150407175619.GI26921@redhat.com> References: <20150407142523.GD26921@redhat.com> <20150407175619.GI26921@redhat.com> Message-ID: HA! yep, re-requesting the cert using version 0.77.1 solved this... I can request a cert and after a manual approval, I'm able to download and monitor the cert. THANK YOU! I'm also having another problem. When I try to use dogtag-submit like this: */usr/libexec/certmonger/dogtag-submit -E https://dogtag.test.org:8443/ca/ee/ca -A https://dogtag.test.org:8443/ca/agent/ca -T caAgentServerCert -i /tmp/test/ca.crt -c /tmp/test/cert.pem -k /tmp/test/key.pem* I get this: *Request ID '20150404113812': status: CA_REJECTED ca-error: Server at "https://dogtag.test.org:8443/ca/ee/ca/profileSubmit " replied: Invalid Credential. stuck: yes key pair storage: type=FILE,location='/etc/ssl/get2cert.key' certificate: type=FILE,location='/etc/ssl/get2cert.crt' CA: DogtagAuto issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes* however, when I use curl like this: *curl "https://dogtag.test.org:8443/ca/ee/ca/profileSubmit?profileId=caAgentServerCert&cert_request_type=pkcs10&cert_request=-----BEGINTE+REQUEST-----%0AMIIFBjCCAu4CAQAwgYUxGzAZBgNVBAoTElRhcmdldCBDb3Jwb3JhdGlvbjEdMBsG%0AA1UECxMUcjUwOSBJbnRlcm1lZGlhdGUgQ0ExFDASBgNVBAcTC01pbm5lYXBvbGlz%0AMRIwEAYDVQQIEwlNaW5uZXNvdGExCzAJBgNVBAYTAlVTMRAwDgYDVQQDEwdyNTA5%0AIENBMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAodOjRhEbG3mKbZPN%0As7dtJgBHBvGksFBvnVXyK2DuY5%2FE7RayxvroQRG42gs5oiEkT4QaCBJlXfsv6NCp%0AiB7btiO9EGlSGcfofAE1ek0plHlh0wtdVJQLMGqbgeaIF8KjV%2FKVBvOtWFjHLLb3%0A92910oUvUxwNffRSDMaOqyAZHdio8r5xUy8zk6dHmpTAdUPSFcmpLaquohCn2cF7%0AAIS0DQ%2Bi0LDSyN1zhbiOTmgT3RiHL%2F5ajZ83VJf3A08FFxGrNCjWdgokBtG4q0FC%0ADCZscy4TJf7BdhVoYBfAwv2G%2FhYiwu7HLwTScGcuIpkMenObO11rtCHrfasb2uLc%0AC2LAxyQ6ML%2FRE8MGzoNXmRLNYx3RdwTPhF73CnmsLt%2BJCgHC7PbRLSk8b6rS9Q7t%0AX8K2Zyx9caU9YDik0ot7bNH1NKFPJUQlAKJ1UAN%2FOjjgDLSsftlc1aPti0d%2Fi70o%0AlGDTj77Zw4T7vdX1h6F8cZTb3u2SmdO00QHZjxn8wsX9QEB7uCuJIg6a9Ui2XlSZ%0A%2BIEtHUEOGq4AEM24bkToaE1qSTXPjGHI41%2BbuOaPDEisganiupnHAhxptqakbpau%0AXY4%2FXEbPFYCAWZd5%2BBcA7KjbOD2l3v6J2ihmB6fOWSp5o08eOmPVy3dB7pfJwx%2F6%0AnHkLKDyeCwV54R5LabuiPjsimVcCAwEAAaA7MDkGCSqGSIb3DQEJDjEsMCowCQYD%0AVR0TBAIwADAdBgNVHQ4EFgQUYW7uTfOlF%2FmwpgUnTr1mapcS2CQwDQYJKoZIhvcN%0AAQELBQADggIBAJVTFpOE1UMuYxAMdaishs7SSnwFuGi55DI6sHe1nIEenlHe4AgE%0AsoQcfCcHv8RvFmE4BHtYEHyDgNc7mraCNmf1j3lPb3nqe33PiEIA6PdB6hjYNB45%0AvklV3N%2FIsHauVg%2FlAm6pCc7oaCJPqLgBc4eSPJd8xef64DuFVUxLSB1LQ3oTpw2T%0AC4Ydg0GCY7t7gZYWaaf5FIY41dtuXAkud5sxpUWwTgRH%2FO%2BrQNP5x8Uy2SKl2QXv%0AQJMzeRLfHdZyFY2utW9BChdmPD%2B%2FLJNwhr924RgzGty%2FrGK7SIAtj%2FRS6gadB2bV%0Ax6Ii9migA7PWDVi9XYzcGiGt1U5jbRsbGh%2Bie8N5MxIW672XqdPz9ocAFu7gfAws%0AnG7%2BcPOiTiEfivOHQ7HpDcSnD9DW2QHc92UzB3tl6vQQ7oQgI1YMtF30D7lOyL8C%0AQ8TcA5fQsVasMhaW78FSaIzJtEWjeQpyg8XCjNtB4Cz4txNaig6YdNer6kFoYiPh%0A5UNVH%2BmeFjJn1fhKq8Imyy6MwHHaZTDsU8I3uUGo6xyIPgKMkLrFsDSo8BumLUGJ%0A56hxNQGixzsO%2B1lIahjBr79Aevzb48l6woMeQBYfLNLKTm290BKXsVgrif19XQ3E%0AZgehMupo%2FZyXjY%2BX4YadNEb8kN5d2cvKCsnjO9urHfAiBPnZtZlYZl1Y%0A-----END+CERTIFICATE+REQUEST-----%0A&xml=true " --pass password --cacert /tmp/test/ca.crt --key /tmp/test/key.pem --cert /tmp/test/client.pem* I get a valid response. *057CN=r509 CA,C=US,ST=Minnesota,L=Minneapolis,OU=r509 Intermediate CA,O=Test Corporation2eMIIE0DCCA7igAwIBAgIBLjANBgkqhkiG9w0BAQsFADBEMSEwHwYDVQQKDBh0ZXN0Lm9yZyBTZWN1cml0eSBEb21haW* *cert data........* *LP15bCE6K5hABEUfrmZiLJvjBQjFx67Bs0vBaDDb1lqJ8pyjzFHhXtDx5g+/YOzzKqoRdN* I'm using a cert and key extracted from the caadmin pkcs12 credentials. Can you confirm this behavior in your test environment? Thanks SO MUCH for your help, --steve On Tue, Apr 7, 2015 at 12:56 PM, Nalin Dahyabhai wrote: > On Tue, Apr 07, 2015 at 12:18:24PM -0500, Steve Neuharth wrote: > > yes, the certificate in the request file has a newline after the > > certificate data: > > > > cert=-----BEGIN CERTIFICATE----- > > MIIDajCCAlKgAwIBAgIBIDANBgkqhkiG9w0BAQsFADBEMSEwHwYDVQQKDBh0ZXN0 > > ...cert data... > > lRCw27w7Yw/JUMqJYoE= > > <---- extra newline > > -----END CERTIFICATE----- > > > > > > Looks like that's the problem. When I make a similar request using cURL, > I > > don't get the '\n' in the xml so it must be an error in parsing the xml > > response inside dogtag-submit. I've also tried the v77.1-1 rpm from > rawhide > > and I get the same behavior. > > Hmm, I'm testing with 0.77.1 and pki-ca-9.0.3-38.el6_6 (you're on Fedora > IIRC, so it's not exactly the same, but I don't have an F21 box handy > ATM), and the data's getting cleaned before it's saved there. > > Did you start with an older version and update after dogtag-submit had > finished its work? The newer daemon wouldn't have been in a position to > clean up the data it got from the helper in that case. > > Nalin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nalin at redhat.com Tue Apr 7 19:22:36 2015 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 7 Apr 2015 15:22:36 -0400 Subject: [Pki-users] getting NEED_TO_NOTIFY_ISSUED_SAVE_FAILED with dogtag-submit In-Reply-To: References: <20150407142523.GD26921@redhat.com> <20150407175619.GI26921@redhat.com> Message-ID: <20150407192236.GJ26921@redhat.com> On Tue, Apr 07, 2015 at 01:58:24PM -0500, Steve Neuharth wrote: > HA! yep, re-requesting the cert using version 0.77.1 solved this... I can > request a cert and after a manual approval, I'm able to download and > monitor the cert. THANK YOU! > > I'm also having another problem. When I try to use dogtag-submit like this: > > */usr/libexec/certmonger/dogtag-submit -E > https://dogtag.test.org:8443/ca/ee/ca > -A > https://dogtag.test.org:8443/ca/agent/ca > -T caAgentServerCert -i > /tmp/test/ca.crt -c /tmp/test/cert.pem -k /tmp/test/key.pem* > > I get this: > > *Request ID '20150404113812': status: CA_REJECTED ca-error: > Server at "https://dogtag.test.org:8443/ca/ee/ca/profileSubmit > " replied: Invalid > Credential. stuck: yes key pair storage: > type=FILE,location='/etc/ssl/get2cert.key' certificate: > type=FILE,location='/etc/ssl/get2cert.crt' CA: DogtagAuto > issuer: subject: expires: unknown pre-save > command: post-save command: track: yes auto-renew: yes* > however, when I use curl like this: > > *curl > "https://dogtag.test.org:8443/ca/ee/ca/profileSubmit?profileId=caAgentServerCert&cert_request_type=pkcs10&cert_request=-----BEGINTE+REQUEST-----%0AMIIFBjCCAu4CAQAwgYUxGzAZBgNVBAoTElRhcmdldCBDb3Jwb3JhdGlvbjEdMBsG%0AA1UECxMUcjUwOSBJbnRlcm1lZGlhdGUgQ0ExFDASBgNVBAcTC01pbm5lYXBvbGlz%0AMRIwEAYDVQQIEwlNaW5uZXNvdGExCzAJBgNVBAYTAlVTMRAwDgYDVQQDEwdyNTA5%0AIENBMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAodOjRhEbG3mKbZPN%0As7dtJgBHBvGksFBvnVXyK2DuY5%2FE7RayxvroQRG42gs5oiEkT4QaCBJlXfsv6NCp%0AiB7btiO9EGlSGcfofAE1ek0plHlh0wtdVJQLMGqbgeaIF8KjV%2FKVBvOtWFjHLLb3%0A92910oUvUxwNffRSDMaOqyAZHdio8r5xUy8zk6dHmpTAdUPSFcmpLaquohCn2cF7%0AAIS0DQ%2Bi0LDSyN1zhbiOTmgT3RiHL%2F5ajZ83VJf3A08FFxGrNCjWdgokBtG4q0FC%0ADCZscy4TJf7BdhVoYBfAwv2G%2FhYiwu7HLwTScGcuIpkMenObO11rtCHrfasb2uLc%0AC2LAxyQ6ML%2FRE8MGzoNXmRLNYx3RdwTPhF73CnmsLt%2BJCgHC7PbRLSk8b6rS9Q7t%0AX8K2Zyx9caU9YDik0ot7bNH1NKFPJUQlAKJ1UAN%2FOjjgDLSsftlc1aPti0d%2Fi70o%0AlGDTj77Zw4T7vdX1h6F8cZTb3u2SmdO00QHZjxn8wsX9QEB7uCuJIg6a9Ui2XlSZ%0A%2BIEtHUEOGq4AEM24bkToaE1qSTXPjGHI41%2BbuOaPDEisganiupnHAhxptqakbpau%0AXY4%2FXEbPFYCAWZd5%2BBcA7KjbOD2l3v6J2ihmB6fOWSp5o08eOmPVy3dB7pfJwx%2F6%0AnHkLKDyeCwV54R5LabuiPjsimVcCAwEAAaA7MDkGCSqGSIb3DQEJDjEsMCowCQYD%0AVR0TBAIwADAdBgNVHQ4EFgQUYW7uTfOlF%2FmwpgUnTr1mapcS2CQwDQYJKoZIhvcN%0AAQELBQADggIBAJVTFpOE1UMuYxAMdaishs7SSnwFuGi55DI6sHe1nIEenlHe4AgE%0AsoQcfCcHv8RvFmE4BHtYEHyDgNc7mraCNmf1j3lPb3nqe33PiEIA6PdB6hjYNB45%0AvklV3N%2FIsHauVg%2FlAm6pCc7oaCJPqLgBc4eSPJd8xef64DuFVUxLSB1LQ3oTpw2T%0AC4Ydg0GCY7t7gZYWaaf5FIY41dtuXAkud5sxpUWwTgRH%2FO%2BrQNP5x8Uy2SKl2QXv%0AQJMzeRLfHdZyFY2utW9BChdmPD%2B%2FLJNwhr924RgzGty%2FrGK7SIAtj%2FRS6gadB2bV%0Ax6Ii9migA7PWDVi9XYzcGiGt1U5jbRsbGh%2Bie8N5MxIW672XqdPz9ocAFu7gfAws%0AnG7%2BcPOiTiEfivOHQ7HpDcSnD9DW2QHc92UzB3tl6vQQ7oQgI1YMtF30D7lOyL8C%0AQ8TcA5fQsVasMhaW78FSaIzJtEWjeQpyg8XCjNtB4Cz4txNaig6YdNer6kFoYiPh%0A5UNVH%2BmeFjJn1fhKq8Imyy6MwHHaZTDsU8I3uUGo6xyIPgKMkLrFsDSo8BumLUGJ%0A56hxNQGixzsO%2B1lIahjBr79Aevzb48l6woMeQBYfLNLKTm290BKXsVgrif19XQ3E%0AZgehMupo%2FZyXjY%2BX4YadNEb8kN5d2cvKCsnjO9urHfAiBPnZtZlYZl1Y%0A-----END+CERTIFICATE+REQUEST-----%0A&xml=true > --pass password --cacert /tmp/test/ca.crt --key /tmp/test/key.pem --cert > /tmp/test/client.pem* > > I get a valid response. Hmm, those two runs may not be using the same agent credentials. Is there a difference between the cert.pem that's being passed to dogtag-submit and the client.pem that's passed to curl? If the private key (key.pem) is encrypted, and curl is being passed the encryption password for it using its --pass option, dogtag-submit probably needs a -P or -p option to provide it with the same value. Alternately, if you're going to do manual approval at the server, you can skip the -A, -c, and -k flags when you run dogtag-submit, and it'll just poll periodically until the CA tells it that the request was either approved or rejected. HTH, Nalin From steve at sylvation.com Tue Apr 7 19:37:12 2015 From: steve at sylvation.com (Steve Neuharth) Date: Tue, 7 Apr 2015 14:37:12 -0500 Subject: [Pki-users] getting NEED_TO_NOTIFY_ISSUED_SAVE_FAILED with dogtag-submit In-Reply-To: <20150407192236.GJ26921@redhat.com> References: <20150407142523.GD26921@redhat.com> <20150407175619.GI26921@redhat.com> <20150407192236.GJ26921@redhat.com> Message-ID: Yes, very observant. I noticed that as well. The difference was that client.pem had some bag information in it: *Bag Attributes friendlyName: PKI Administrator for test.org localKeyID: 4F E5 46 3D foo 64 1F E4subject=/O=test.org Security Domain/emailAddress=caadmin at test.org/CN=PKI Administratorissuer=/O=test.org Security Domain/CN=CA Signing Certificate* while cert.pem does not. otherwise, they contain the same cert data. --password was just in there because it was in my command history, I have since stripped the password off of the key (openssl --norsa) and curl does work without the --password switch. I'm actually planning on using automatically approved certs eventually and so it is my desire to use either username/password or cert/key authentication to facilitate that. I just noticed that the dogtag-submit does not seem to use my cert/key pair when I specify them. Does certificate authentication work for you in dogtag-submit? On Tue, Apr 7, 2015 at 2:22 PM, Nalin Dahyabhai wrote: > On Tue, Apr 07, 2015 at 01:58:24PM -0500, Steve Neuharth wrote: > > HA! yep, re-requesting the cert using version 0.77.1 solved this... I can > > request a cert and after a manual approval, I'm able to download and > > monitor the cert. THANK YOU! > > > > I'm also having another problem. When I try to use dogtag-submit like > this: > > > > */usr/libexec/certmonger/dogtag-submit -E > > https://dogtag.test.org:8443/ca/ee/ca > > -A > > https://dogtag.test.org:8443/ca/agent/ca > > -T caAgentServerCert -i > > /tmp/test/ca.crt -c /tmp/test/cert.pem -k /tmp/test/key.pem* > > > > I get this: > > > > *Request ID '20150404113812': status: CA_REJECTED ca-error: > > Server at "https://dogtag.test.org:8443/ca/ee/ca/profileSubmit > > " replied: Invalid > > Credential. stuck: yes key pair storage: > > type=FILE,location='/etc/ssl/get2cert.key' certificate: > > type=FILE,location='/etc/ssl/get2cert.crt' CA: DogtagAuto > > issuer: subject: expires: unknown pre-save > > command: post-save command: track: yes auto-renew: > yes* > > however, when I use curl like this: > > > > *curl > > " > https://dogtag.test.org:8443/ca/ee/ca/profileSubmit?profileId=caAgentServerCert&cert_request_type=pkcs10&cert_request=-----BEGINTE+REQUEST-----%0AMIIFBjCCAu4CAQAwgYUxGzAZBgNVBAoTElRhcmdldCBDb3Jwb3JhdGlvbjEdMBsG%0AA1UECxMUcjUwOSBJbnRlcm1lZGlhdGUgQ0ExFDASBgNVBAcTC01pbm5lYXBvbGlz%0AMRIwEAYDVQQIEwlNaW5uZXNvdGExCzAJBgNVBAYTAlVTMRAwDgYDVQQDEwdyNTA5%0AIENBMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAodOjRhEbG3mKbZPN%0As7dtJgBHBvGksFBvnVXyK2DuY5%2FE7RayxvroQRG42gs5oiEkT4QaCBJlXfsv6NCp%0AiB7btiO9EGlSGcfofAE1ek0plHlh0wtdVJQLMGqbgeaIF8KjV%2FKVBvOtWFjHLLb3%0A92910oUvUxwNffRSDMaOqyAZHdio8r5xUy8zk6dHmpTAdUPSFcmpLaquohCn2cF7%0AAIS0DQ%2Bi0LDSyN1zhbiOTmgT3RiHL%2F5ajZ83VJf3A08FFxGrNCjWdgokBtG4q0FC%0ADCZscy4TJf7BdhVoYBfAwv2G%2FhYiwu7HLwTScGcuIpkMenObO11rtCHrfasb2uLc%0AC2LAxyQ6ML%2FRE8MGzoNXmRLNYx3RdwTPhF73CnmsLt%2BJCgHC7PbRLSk8b6rS9Q7t%0AX8K2Zyx9caU9YDik0ot7bNH1NKFPJUQlAKJ1UAN%2FOjjgDLSsftlc1aPti0d%2Fi70o%0AlGDTj77Zw4T7vdX1h6F8cZTb3u2SmdO00QHZjxn8wsX9QEB7uCuJIg6a9Ui2XlSZ%0A%2BIEtHUEOGq4AEM24bkToaE1qSTXPjGHI41%2BbuOaPDEisganiupnHAhxptqakbpau%0AXY4%2FXEbPFYCAWZd5%2BBcA7KjbOD2l3v6J2ihmB6fOWSp5o08eOmPVy3dB7pfJwx%2F6%0AnHkLKDyeCwV54R5LabuiPjsimVcCAwEAAaA7MDkGCSqGSIb3DQEJDjEsMCowCQYD%0AVR0TBAIwADAdBgNVHQ4EFgQUYW7uTfOlF%2FmwpgUnTr1mapcS2CQwDQYJKoZIhvcN%0AAQELBQADggIBAJVTFpOE1UMuYxAMdaishs7SSnwFuGi55DI6sHe1nIEenlHe4AgE%0AsoQcfCcHv8RvFmE4BHtYEHyDgNc7mraCNmf1j3lPb3nqe33PiEIA6PdB6hjYNB45%0AvklV3N%2FIsHauVg%2FlAm6pCc7oaCJPqLgBc4eSPJd8xef64DuFVUxLSB1LQ3oTpw2T%0AC4Ydg0GCY7t7gZYWaaf5FIY41dtuXAkud5sxpUWwTgRH%2FO%2BrQNP5x8Uy2SKl2QXv%0AQJMzeRLfHdZyFY2utW9BChdmPD%2B%2FLJNwhr924RgzGty%2FrGK7SIAtj%2FRS6gadB2bV%0Ax6Ii9migA7PWDVi9XYzcGiGt1U5jbRsbGh%2Bie8N5MxIW672XqdPz9ocAFu7gfAws%0AnG7%2BcPOiTiEfivOHQ7HpDcSnD9DW2QHc92UzB3tl6vQQ7oQgI1YMtF30D7lOyL8C%0AQ8TcA5fQsVasMhaW78FSaIzJtEWjeQpyg8XCjNtB4Cz4txNaig6YdNer6kFoYiPh%0A5UNVH%2BmeFjJn1fhKq8Imyy6MwHHaZTDsU8I3uUGo6xyIPgKMkLrFsDSo8BumLUGJ%0A56hxNQGixzsO%2B1lIahjBr79Aevzb48l6woMeQBYfLNLKTm290BKXsVgrif19XQ3E%0AZgehMupo%2FZyXjY%2BX4YadNEb8kN5d2cvKCsnjO9urHfAiBPnZtZlYZl1Y%0A-----END+CERTIFICATE+REQUEST-----%0A&xml=true > > --pass password --cacert /tmp/test/ca.crt --key /tmp/test/key.pem --cert > > /tmp/test/client.pem* > > > > I get a valid response. > > Hmm, those two runs may not be using the same agent credentials. > > Is there a difference between the cert.pem that's being passed to > dogtag-submit and the client.pem that's passed to curl? > > If the private key (key.pem) is encrypted, and curl is being passed the > encryption password for it using its --pass option, dogtag-submit > probably needs a -P or -p option to provide it with the same value. > > Alternately, if you're going to do manual approval at the server, you > can skip the -A, -c, and -k flags when you run dogtag-submit, and it'll > just poll periodically until the CA tells it that the request was either > approved or rejected. > > HTH, > > Nalin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nalin at redhat.com Tue Apr 7 19:57:36 2015 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 7 Apr 2015 15:57:36 -0400 Subject: [Pki-users] getting NEED_TO_NOTIFY_ISSUED_SAVE_FAILED with dogtag-submit In-Reply-To: References: <20150407142523.GD26921@redhat.com> <20150407175619.GI26921@redhat.com> <20150407192236.GJ26921@redhat.com> Message-ID: <20150407195736.GK26921@redhat.com> On Tue, Apr 07, 2015 at 02:37:12PM -0500, Steve Neuharth wrote: > Yes, very observant. I noticed that as well. The difference was that > client.pem had some bag information in it: > > *Bag Attributes friendlyName: PKI Administrator for test.org > localKeyID: 4F E5 46 3D foo 64 1F > E4subject=/O=test.org Security > Domain/emailAddress=caadmin at test.org/CN=PKI > Administratorissuer=/O=test.org > Security Domain/CN=CA Signing Certificate* > while cert.pem does not. otherwise, they contain the same cert data. Right, you mentioned that you'd pulled the key and certificate out of a PKCS#12 bundle, so it makes sense that that'd show up there. > I'm actually planning on using automatically approved certs eventually and > so it is my desire to use either username/password or cert/key > authentication to facilitate that. I just noticed that the dogtag-submit > does not seem to use my cert/key pair when I specify them. > > Does certificate authentication work for you in dogtag-submit? It does, but I'd been using an NSS database (-d and -n flags) rather than PEM-formatted keys and certificates. And -i to point to a PEM-format certificate, and the -p flag, so it looked like this: /usr/libexec/certmonger/dogtag-submit -E http://machete.bos.redhat.com:9180/ca/ee/ca -A https://machete.bos.redhat.com:9443/ca/agent/ca -d /etc/httpd/alias -n ipaCert -i /etc/ipa/ca.crt -p /etc/httpd/alias/pwdfile.txt When I used "openssl pkcs12 -in /root/ca-agent.p12 -nodes -nokeys -out /etc/pki/tls/certs/agent.cert" to extract the certificates, I had to prune out everything but the agent certificate itself, and the agent key itself, to avoid getting SSL connect errors, though that may only be necessary with the older version of NSS's PEM module that my test system has. The working invocation I ended up with looks like this: /usr/libexec/certmonger/dogtag-submit -E http://machete.bos.redhat.com:9180/ca/ee/ca -A https://machete.bos.redhat.com:9443/ca/agent/ca -k /etc/pki/tls/private/agent.key -c /etc/pki/tls/certs/agent.cert -i /etc/ipa/ca.crt I'm not sure if you're in SELinux enforcing mode, but if you are, the daemon (and the helpers that it starts) may not be able to read the files under /tmp/test unless they're labeled to allow it. HTH, Nalin From steve at sylvation.com Wed Apr 8 14:35:31 2015 From: steve at sylvation.com (Steve Neuharth) Date: Wed, 8 Apr 2015 09:35:31 -0500 Subject: [Pki-users] getting NEED_TO_NOTIFY_ISSUED_SAVE_FAILED with dogtag-submit In-Reply-To: <20150407195736.GK26921@redhat.com> References: <20150407142523.GD26921@redhat.com> <20150407175619.GI26921@redhat.com> <20150407192236.GJ26921@redhat.com> <20150407195736.GK26921@redhat.com> Message-ID: yes, I have indeed set SELinux to permissive to eliminate any potential security collisions. If I configure my 'DogtagAuto' CA in /var/lib/certmonger/cas without the '-T caAgentServerCert', the certmonger daemon dies as soon as I request a certificate using that CA. Other than that, it looks like I'm using the same flags as you. when I run dogtag-submit this way manually (without the template), I see that it reutrns: results = "2Request Deferred - {0} 70" 0 state=approve&requestId=70 I find it strange that this response would crash certmonger. Also, wouldn't I need to specify a template if I need to automatically sign the cert and get the cert immediately? On Tue, Apr 7, 2015 at 2:57 PM, Nalin Dahyabhai wrote: > On Tue, Apr 07, 2015 at 02:37:12PM -0500, Steve Neuharth wrote: > > Yes, very observant. I noticed that as well. The difference was that > > client.pem had some bag information in it: > > > > *Bag Attributes friendlyName: PKI Administrator for test.org > > localKeyID: 4F E5 46 3D foo 64 1F > > E4subject=/O=test.org Security > > Domain/emailAddress=caadmin at test.org/CN=PKI > > Administratorissuer=/O=test.org > > Security Domain/CN=CA Signing Certificate* > > while cert.pem does not. otherwise, they contain the same cert data. > > Right, you mentioned that you'd pulled the key and certificate out of a > PKCS#12 bundle, so it makes sense that that'd show up there. > > > I'm actually planning on using automatically approved certs eventually > and > > so it is my desire to use either username/password or cert/key > > authentication to facilitate that. I just noticed that the dogtag-submit > > does not seem to use my cert/key pair when I specify them. > > > > Does certificate authentication work for you in dogtag-submit? > > It does, but I'd been using an NSS database (-d and -n flags) rather > than PEM-formatted keys and certificates. And -i to point to a > PEM-format certificate, and the -p flag, so it looked like this: > /usr/libexec/certmonger/dogtag-submit -E > http://machete.bos.redhat.com:9180/ca/ee/ca -A > https://machete.bos.redhat.com:9443/ca/agent/ca -d /etc/httpd/alias -n > ipaCert -i /etc/ipa/ca.crt -p /etc/httpd/alias/pwdfile.txt > > When I used "openssl pkcs12 -in /root/ca-agent.p12 -nodes -nokeys -out > /etc/pki/tls/certs/agent.cert" to extract the certificates, I had to > prune out everything but the agent certificate itself, and the agent key > itself, to avoid getting SSL connect errors, though that may only be > necessary with the older version of NSS's PEM module that my test system > has. The working invocation I ended up with looks like this: > /usr/libexec/certmonger/dogtag-submit -E > http://machete.bos.redhat.com:9180/ca/ee/ca -A > https://machete.bos.redhat.com:9443/ca/agent/ca -k > /etc/pki/tls/private/agent.key -c /etc/pki/tls/certs/agent.cert -i > /etc/ipa/ca.crt > > I'm not sure if you're in SELinux enforcing mode, but if you are, the > daemon (and the helpers that it starts) may not be able to read the > files under /tmp/test unless they're labeled to allow it. > > HTH, > > Nalin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nalin at redhat.com Wed Apr 8 21:35:46 2015 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 8 Apr 2015 17:35:46 -0400 Subject: [Pki-users] getting NEED_TO_NOTIFY_ISSUED_SAVE_FAILED with dogtag-submit In-Reply-To: References: <20150407142523.GD26921@redhat.com> <20150407175619.GI26921@redhat.com> <20150407192236.GJ26921@redhat.com> <20150407195736.GK26921@redhat.com> Message-ID: <20150408213546.GA1294@redhat.com> On Wed, Apr 08, 2015 at 09:35:31AM -0500, Steve Neuharth wrote: > yes, I have indeed set SELinux to permissive to eliminate any potential > security collisions. > > If I configure my 'DogtagAuto' CA in /var/lib/certmonger/cas without the '-T > caAgentServerCert', the certmonger daemon dies as soon as I request a > certificate using that CA. Other than that, it looks like I'm using the > same flags as you. Well, it shouldn't be dying at least. If you can get a coredump or a backtrace out of it, that'll help track it down. I'm not really sure how the use (or not) of the -T flag with the helper could be affecting that, though, as when I tried obtaining a certificate using it and the caServerCert profile, it succeeded. I got an authentication error attempting to specify the caAgentServerCert profile, which makes some sense since the helper submits the request using using the end-entity services interface and only uses the agent creds when it goes back to approve it using the agent services interface. > when I run dogtag-submit this way manually (without the template), I see > that it reutrns: results = " standalone="no"?>2Request Deferred - > {0} 70" > 0 > state=approve&requestId=70 > > I find it strange that this response would crash certmonger. Also, wouldn't > I need to specify a template if I need to automatically sign the cert and > get the cert immediately? The helper hard-codes a default of "caServerCert" if the flag isn't used, and that looks like a pretty normal delay-and-state-cookie output value to me, so a backtrace would be really helpful in diagnosing what's happening when you try it. HTH, Nalin From Emily at arcananet.com Wed Apr 8 21:38:38 2015 From: Emily at arcananet.com (Emily Stemmerich) Date: Wed, 8 Apr 2015 21:38:38 +0000 Subject: [Pki-users] Router identity certificate auto-renewal questions Message-ID: Hi, I was referred to this email list by alee on the #dogtag-pki IRC group to get some help on automatic certificate renewals. We are trying to get Dogtag 10.2.1 set up to be a certificate authority for Cisco routers? identity certificates. For the first step I have things working to get a certificate using the caRouterCert.cfg profile with a one-time password in the flatfile.txt. For the second step I?m trying to get auto-renewal of the identity certificates working. Here is where I stand: 1. For testing, I have set the validity to 1 day so that the renewal attempt happens the next day? I don?t see a way of making it any shorter to expedite testing. 2. I have added ?renewal=true? to the caRouterCert.cfg hoping that it will enable auto-renewal. I?m not sure if using the same profile would require that a ?one-time? password needs to be in flatfile.txt again (which isn?t practical)? If I would need a different profile for the renewal I?m not clear on how to add and then use it for the renewal. 3. I have renewal.graceBefore=10 and renewal.graceAfter=1 in the profile just for testing purposes. 4. I have confirmed on the router that the expiration is as expected (24hrs) and it shows a date/time that it will attempt to renew automatically (the link below discusses cert renewal from the perspective of IOS). http://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/116094-maintain-ios-pki.html#anc8 5. When the renewal time comes on the router, I see lots of activity in the dogtag debug log, but am unsure of what to look for to troubleshoot it failing. Please advise on what to change and/or look for. I can also send logs and/or config files if that would help. Best Regards, -Emily -------------- next part -------------- An HTML attachment was scrubbed... URL: From rperez at fiscaliatabasco.gob.mx Thu Apr 9 05:37:41 2015 From: rperez at fiscaliatabasco.gob.mx (Ricardo Alexander Alexander Perez Ricardez) Date: Thu, 9 Apr 2015 00:37:41 -0500 (CDT) Subject: [Pki-users] Validate OCSP responder In-Reply-To: <1423774779.71916.1428557847560.JavaMail.root@fiscaliatabasco.gob.mx> Message-ID: <823214069.71918.1428557861613.JavaMail.root@fiscaliatabasco.gob.mx> Is there any way to validate if the OCSP responder is working correctly on the client side? From rperez at fiscaliatabasco.gob.mx Thu Apr 9 05:50:53 2015 From: rperez at fiscaliatabasco.gob.mx (Ricardo Alexander Alexander Perez Ricardez) Date: Thu, 9 Apr 2015 00:50:53 -0500 (CDT) Subject: [Pki-users] Check version of dogtag certificate system Message-ID: <549977482.71922.1428558653963.JavaMail.root@fiscaliatabasco.gob.mx> Hi, How to check what version of dogtag certficate system is installed on my system? From Majain at verisign.com Thu Apr 9 19:23:14 2015 From: Majain at verisign.com (Jain, Mahendra) Date: Thu, 9 Apr 2015 19:23:14 +0000 Subject: [Pki-users] How to setup PKI Administrator user In-Reply-To: <551978C4.7090802@redhat.com> References: <551978C4.7090802@redhat.com> Message-ID: Thanks Niranjan, I submitted 'Manual User Dual-Use Certificate Enrollment? via End User interface and got it approved via agent interface and imported it to browser including the keys. My confusion is where the keys (private key) came from? Was it automatically generated when I submitted the Certificate Enrollment request via browser? Or was it created by the Dogtag server and delivered it to browser when I imported the cert? Thanks in advance. Mahendra On 3/30/15, 12:24 PM, "Niranjan M.R" wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On 03/30/2015 09:16 PM, Jain, Mahendra wrote: >> Hello All, >> >> When I install the Dogtag Certificate System, the installation creates >>default PKI Administrator user (caadmin). >> What is the procedure to setup additional PKI Administrator users so >>that they can also access agent interface? >If you are on latest dogtag (fedora 20), you could pki user cli to create >user and add him to Certificate Manager Agents Group . >Also use a user profile to generate cert for the new user and add the >cert using pki user cli . Import the cert to browser (including keys). > >You could do the same using pkiconsole too. > >> >> Thanks, >> Mahendra >> >> >> ?This message (including any attachments) is intended only >>for the use of the individual or entity to which it is addressed, and >>may contain >> information that is non-public, proprietary, privileged, >>confidential and exempt from disclosure under applicable law or may be >>constituted >> as attorney work product. If you are not the intended >>recipient, you are hereby notified that any use, dissemination, >>distribution, or >> copying of this communication is strictly prohibited. If you >>have received this message in error, notify sender immediately and >>delete this >> message immediately.? >> >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> > > >- -- >Niranjan >irc: mrniranjan >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1 > >iKYEARECAGYFAlUZeMRfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl >bnBncC5maWZ0aGhvcnNlbWFuLm5ldEY3OTE3QTg3ODE0RkVCQ0YyNjgyOTRENjJF >RURDNTVGNjA0N0M3QzcACgkQLu3FX2BHx8dsCwCgh14OK+0ZFyFYUWkEt04Idgq0 >E4kAoIohPEYgdwXYLXPiMunLSyDhEOQz >=766t >-----END PGP SIGNATURE----- From edewata at redhat.com Thu Apr 9 21:29:07 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 09 Apr 2015 16:29:07 -0500 Subject: [Pki-users] How to setup PKI Administrator user In-Reply-To: References: <551978C4.7090802@redhat.com> Message-ID: <5526EF23.6060407@redhat.com> On 4/9/2015 2:23 PM, Jain, Mahendra wrote: > Thanks Niranjan, > > I submitted 'Manual User Dual-Use Certificate Enrollment? via End User > interface and got it approved via agent interface and imported it to > browser including the keys. > > My confusion is where the keys (private key) came from? Was it > automatically generated when I submitted the Certificate Enrollment > request via browser? Or was it created by the Dogtag server and delivered > it to browser when I imported the cert? > > > Thanks in advance. > Mahendra > To my understanding the current UI relies on a Firefox feature to generate a private key in the browser. However, this feature is going away in future Firefox, so Dogtag is now providing a way to generate a private key using the CLI: http://pki.fedoraproject.org/wiki/User_Certificate The private key later can be imported into Firefox. If you want to use a non-root Linux user as CA admin with a new certificate, follow the above page to generate the certificate, then add the user into the admin group. If you want to use a non-root Linux user as CA admin with existing CA admin certificate, follow this instruction: http://pki.fedoraproject.org/wiki/CA_Admin_Setup -- Endi S. Dewata From Majain at verisign.com Fri Apr 10 00:32:55 2015 From: Majain at verisign.com (Jain, Mahendra) Date: Fri, 10 Apr 2015 00:32:55 +0000 Subject: [Pki-users] How to setup PKI Administrator user In-Reply-To: <5526EF23.6060407@redhat.com> References: <551978C4.7090802@redhat.com> <5526EF23.6060407@redhat.com> Message-ID: Thanks Endi for the quick response. On 4/9/15, 5:29 PM, "Endi Sukma Dewata" wrote: >On 4/9/2015 2:23 PM, Jain, Mahendra wrote: >> Thanks Niranjan, >> >> I submitted 'Manual User Dual-Use Certificate Enrollment? via End User >> interface and got it approved via agent interface and imported it to >> browser including the keys. >> >> My confusion is where the keys (private key) came from? Was it >> automatically generated when I submitted the Certificate Enrollment >> request via browser? Or was it created by the Dogtag server and >>delivered >> it to browser when I imported the cert? >> >> >> Thanks in advance. >> Mahendra >> > >To my understanding the current UI relies on a Firefox feature to >generate a private key in the browser. However, this feature is going >away in future Firefox, so Dogtag is now providing a way to generate a >private key using the CLI: >http://pki.fedoraproject.org/wiki/User_Certificate >The private key later can be imported into Firefox. > >If you want to use a non-root Linux user as CA admin with a new >certificate, follow the above page to generate the certificate, then add >the user into the admin group. > >If you want to use a non-root Linux user as CA admin with existing CA >admin certificate, follow this instruction: >http://pki.fedoraproject.org/wiki/CA_Admin_Setup > >-- >Endi S. Dewata From mharmsen at redhat.com Fri Apr 10 00:35:21 2015 From: mharmsen at redhat.com (Matthew Harmsen) Date: Thu, 09 Apr 2015 18:35:21 -0600 Subject: [Pki-users] Check version of dogtag certificate system In-Reply-To: <549977482.71922.1428558653963.JavaMail.root@fiscaliatabasco.gob.mx> References: <549977482.71922.1428558653963.JavaMail.root@fiscaliatabasco.gob.mx> Message-ID: <55271AC9.3000401@redhat.com> On 04/08/15 23:50, Ricardo Alexander Alexander Perez Ricardez wrote: > Hi, > > How to check what version of dogtag certficate system is installed on my system? > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users Ricardo, You can check what version of Dogtag you are running by the RPM Name-Version-Release (NVR) via the command-line: * rpm -qa pki-server pki-server-10.2.2-0.1.fc21.noarch In the above example, a Fedora 21 machine contains Dogtag 10.2.2. For the latest Dogtag versions on various platforms, see the following: * http://pki.fedoraproject.org/wiki/Dogtag_branches_and_releases Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at sylvation.com Fri Apr 10 12:44:16 2015 From: steve at sylvation.com (Steve Neuharth) Date: Fri, 10 Apr 2015 07:44:16 -0500 Subject: [Pki-users] getting NEED_TO_NOTIFY_ISSUED_SAVE_FAILED with dogtag-submit In-Reply-To: <20150408213546.GA1294@redhat.com> References: <20150407142523.GD26921@redhat.com> <20150407175619.GI26921@redhat.com> <20150407192236.GJ26921@redhat.com> <20150407195736.GK26921@redhat.com> <20150408213546.GA1294@redhat.com> Message-ID: sure... let me get you a trace. Are there any specific flags I should set in strace? Also... when I request a cert using caServerCert and approve it in DogTag, the certmonger request sits in CA_WORKING status for a while. How long can I expect it to stay that way? I've always been impatient and done a *getcert refresh *on the request to force a download but is there a configurable poll interval or anything? I didn't see anything obvious in the docs. --steve On Wed, Apr 8, 2015 at 4:35 PM, Nalin Dahyabhai wrote: > On Wed, Apr 08, 2015 at 09:35:31AM -0500, Steve Neuharth wrote: > > yes, I have indeed set SELinux to permissive to eliminate any potential > > security collisions. > > > > If I configure my 'DogtagAuto' CA in /var/lib/certmonger/cas without the > '-T > > caAgentServerCert', the certmonger daemon dies as soon as I request a > > certificate using that CA. Other than that, it looks like I'm using the > > same flags as you. > > Well, it shouldn't be dying at least. If you can get a coredump or a > backtrace out of it, that'll help track it down. I'm not really sure > how the use (or not) of the -T flag with the helper could be affecting > that, though, as when I tried obtaining a certificate using it and the > caServerCert profile, it succeeded. > > I got an authentication error attempting to specify the > caAgentServerCert profile, which makes some sense since the helper > submits the request using using the end-entity services interface and > only uses the agent creds when it goes back to approve it using the > agent services interface. > > > when I run dogtag-submit this way manually (without the template), I see > > that it reutrns: results = " > standalone="no"?>2Request Deferred - > > {0} 70" > > 0 > > state=approve&requestId=70 > > > > I find it strange that this response would crash certmonger. Also, > wouldn't > > I need to specify a template if I need to automatically sign the cert and > > get the cert immediately? > > The helper hard-codes a default of "caServerCert" if the flag isn't > used, and that looks like a pretty normal delay-and-state-cookie output > value to me, so a backtrace would be really helpful in diagnosing what's > happening when you try it. > > HTH, > > Nalin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nalin at redhat.com Fri Apr 10 13:29:17 2015 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 10 Apr 2015 09:29:17 -0400 Subject: [Pki-users] getting NEED_TO_NOTIFY_ISSUED_SAVE_FAILED with dogtag-submit In-Reply-To: References: <20150407142523.GD26921@redhat.com> <20150407175619.GI26921@redhat.com> <20150407192236.GJ26921@redhat.com> <20150407195736.GK26921@redhat.com> <20150408213546.GA1294@redhat.com> Message-ID: <20150410132917.GA8197@redhat.com> On Fri, Apr 10, 2015 at 07:44:16AM -0500, Steve Neuharth wrote: > sure... let me get you a trace. Are there any specific flags I should set > in strace? Under strace, I'd tend to use -s256 or larger to try to see more of messages that are going over the bus or the network (larger values if messages are still getting truncated), and if there's a core dump, the backtrace from that, preferably with the certmonger-debuginfo package installed so that gdb can provide more details about where the crash is happening. > Also... when I request a cert using caServerCert and approve it in DogTag, > the certmonger request sits in CA_WORKING status for a while. How long can > I expect it to stay that way? If the server or helper can advise how long the daemon should wait before it polls again, it'll be prepend the amount of time to wait, in seconds, to the output (when using agent creds, the helper advises 0, for no waiting period) and the exit status will be 5. If it doesn't have a value to advise (when it doesn't have agent creds), it'll skip outputting that and will indicate that by using exit status 1. In both cases, if there's a state value that the helper will need to be passed the next time it's called, it then outputs that. Getting a certificate from dogtag is a multi-step process, and the helper uses this to have the certmonger daemon run each step separately, which is intended to make it easier to resume or retry at each individual step if we hit a connectivity problem or the system gets rebooted. > I've always been impatient and done a *getcert refresh *on the request to > force a download but is there a configurable poll interval or anything? I > didn't see anything obvious in the docs. Absent any good idea of how quickly or slowly we can expect a manual approval to happen, the default guess is half of the remaining validity time if we already have a certificate, or a week, whichever is less, with a minimum of five minutes. That's not currently configurable, but the boundaries and the defaults could be made configurable if need be. HTH, Nalin From cfu at redhat.com Fri Apr 10 16:14:34 2015 From: cfu at redhat.com (Christina Fu) Date: Fri, 10 Apr 2015 09:14:34 -0700 Subject: [Pki-users] Router identity certificate auto-renewal questions In-Reply-To: References: Message-ID: <5527F6EA.2020502@redhat.com> Hi Emily, Please see my in-line reply below. Actually, you might want to read my last comment first, and then circle back, so you won't get confused. Christina On 04/08/2015 02:38 PM, Emily Stemmerich wrote: > Hi, > > I was referred to this email list by alee on the #dogtag-pki IRC group > to get some help on automatic certificate renewals. We are trying to > get Dogtag 10.2.1 set up to be a certificate authority for Cisco > routers' identity certificates. For the first step I have things > working to get a certificate using the caRouterCert.cfg profile with a > one-time password in the flatfile.txt. For the second step I'm trying > to get auto-renewal of the identity certificates working. Here is > where I stand: > If you intend to do auto-enrollment, then one-time pin is not the right authentication method. See my reply to #2 below. > 1. For testing, I have set the validity to 1 day so that the renewal > attempt happens the next day... I don't see a way of making it any > shorter to expedite testing. a trick I hear in testing is to reset the clock > > 2. I have added "renewal=true" to the caRouterCert.cfg hoping that it > will enable auto-renewal. I'm not sure if using the same profile > would require that a "one-time" password needs to be in flatfile.txt > again (which isn't practical)? If I would need a different profile > for the renewal I'm not clear on how to add and then use it for the > renewal. the caRouterCert profile works just like all the other profiles where the authentication/authorization are configurable. Here is a link that explains how authentication works and how to configure in profiles: https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Authentication_for_Enrolling_Certificates.html You have choices of authentication. For example, if you want auto-approval (without agent manual approval), you will need to set up directory-based authentication. > > 3. I have renewal.graceBefore=10 and renewal.graceAfter=1 in the > profile just for testing purposes. > > 4. I have confirmed on the router that the expiration is as expected > (24hrs) and it shows a date/time that it will attempt to renew > automatically (the link below discusses cert renewal from the > perspective of IOS). > http://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/116094-maintain-ios-pki.html#anc8 > > 5. When the renewal time comes on the router, I see lots of activity > in the dogtag debug log, but am unsure of what to look for to > troubleshoot it failing. Please note that the renewal feature is not intended for the router. You can read the doc here: https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Renewing_Certificates.html In case of router renewal, you just need to go through the same caRouterCert profile. As you can see from the renewal link above, renewal can take two forms: 1. reuse keys - in this case, you just need to resubmit the same request 2. new keys - in this case, you generate a new request to submit Hope this helps. Christina > > Please advise on what to change and/or look for. I can also send logs > and/or config files if that would help. > > Best Regards, > -Emily > > > > > _______________________________________________ > 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 Emily at arcananet.com Thu Apr 9 18:56:59 2015 From: Emily at arcananet.com (Emily Stemmerich) Date: Thu, 9 Apr 2015 18:56:59 +0000 Subject: [Pki-users] subscribe Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From Emily at arcananet.com Fri Apr 10 17:09:57 2015 From: Emily at arcananet.com (Emily Stemmerich) Date: Fri, 10 Apr 2015 17:09:57 +0000 Subject: [Pki-users] Check version of dogtag certificate system In-Reply-To: <55271AC9.3000401@redhat.com> References: <549977482.71922.1428558653963.JavaMail.root@fiscaliatabasco.gob.mx> <55271AC9.3000401@redhat.com> Message-ID: You can just simply run 'pki --version' to see the version output. -Emily From: Matthew Harmsen > Date: Thursday, April 9, 2015 at 5:35 PM To: Ricardo Alexander Alexander Perez Ricardez >, "pki-users at redhat.com" > Subject: Re: [Pki-users] Check version of dogtag certificate system On 04/08/15 23:50, Ricardo Alexander Alexander Perez Ricardez wrote: Hi, How to check what version of dogtag certficate system is installed on my system? _______________________________________________ Pki-users mailing list Pki-users at redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users Ricardo, You can check what version of Dogtag you are running by the RPM Name-Version-Release (NVR) via the command-line: * rpm -qa pki-server pki-server-10.2.2-0.1.fc21.noarch In the above example, a Fedora 21 machine contains Dogtag 10.2.2. For the latest Dogtag versions on various platforms, see the following: * http://pki.fedoraproject.org/wiki/Dogtag_branches_and_releases Thanks, -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From rperez at fiscaliatabasco.gob.mx Fri Apr 10 19:33:33 2015 From: rperez at fiscaliatabasco.gob.mx (Ricardo Alexander Alexander Perez Ricardez) Date: Fri, 10 Apr 2015 14:33:33 -0500 (CDT) Subject: [Pki-users] Publishing module is disabled In-Reply-To: <685118408.74968.1428694289144.JavaMail.root@fiscaliatabasco.gob.mx> Message-ID: <200786892.75093.1428694413040.JavaMail.root@fiscaliatabasco.gob.mx> When I try Update Directory Server, I recieve message: "Publishing module is disabled" Step 1: Step 2: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: update_directory.png Type: image/png Size: 86359 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: update_directory2.png Type: image/png Size: 40198 bytes Desc: not available URL: From cfu at redhat.com Fri Apr 10 22:02:29 2015 From: cfu at redhat.com (Christina Fu) Date: Fri, 10 Apr 2015 15:02:29 -0700 Subject: [Pki-users] Router identity certificate auto-renewal questions In-Reply-To: <5527F6EA.2020502@redhat.com> References: <5527F6EA.2020502@redhat.com> Message-ID: <55284875.7050903@redhat.com> reposting, since I Emily possibly joined the mailing list after I replied ;-). Christina On 04/10/2015 09:14 AM, Christina Fu wrote: > Hi Emily, > Please see my in-line reply below. > Actually, you might want to read my last comment first, and then > circle back, so you won't get confused. > > Christina > > On 04/08/2015 02:38 PM, Emily Stemmerich wrote: >> Hi, >> >> I was referred to this email list by alee on the #dogtag-pki IRC >> group to get some help on automatic certificate renewals. We are >> trying to get Dogtag 10.2.1 set up to be a certificate authority for >> Cisco routers' identity certificates. For the first step I have >> things working to get a certificate using the caRouterCert.cfg >> profile with a one-time password in the flatfile.txt. For the second >> step I'm trying to get auto-renewal of the identity certificates >> working. Here is where I stand: >> > If you intend to do auto-enrollment, then one-time pin is not the > right authentication method. See my reply to #2 below. > >> 1. For testing, I have set the validity to 1 day so that the renewal >> attempt happens the next day... I don't see a way of making it any >> shorter to expedite testing. > a trick I hear in testing is to reset the clock > >> >> 2. I have added "renewal=true" to the caRouterCert.cfg hoping that it >> will enable auto-renewal. I'm not sure if using the same profile >> would require that a "one-time" password needs to be in flatfile.txt >> again (which isn't practical)? If I would need a different profile >> for the renewal I'm not clear on how to add and then use it for the >> renewal. > the caRouterCert profile works just like all the other profiles where > the authentication/authorization are configurable. > Here is a link that explains how authentication works and how to > configure in profiles: > https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Authentication_for_Enrolling_Certificates.html > > You have choices of authentication. For example, if you want > auto-approval (without agent manual approval), you will need to set up > directory-based authentication. > >> >> 3. I have renewal.graceBefore=10 and renewal.graceAfter=1 in the >> profile just for testing purposes. >> >> 4. I have confirmed on the router that the expiration is as expected >> (24hrs) and it shows a date/time that it will attempt to renew >> automatically (the link below discusses cert renewal from the >> perspective of IOS). >> http://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/116094-maintain-ios-pki.html#anc8 >> >> 5. When the renewal time comes on the router, I see lots of activity >> in the dogtag debug log, but am unsure of what to look for to >> troubleshoot it failing. > > Please note that the renewal feature is not intended for the router. > You can read the doc here: > https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Renewing_Certificates.html > > In case of router renewal, you just need to go through the same > caRouterCert profile. As you can see from the renewal link above, > renewal can take two forms: > 1. reuse keys - in this case, you just need to resubmit the same request > 2. new keys - in this case, you generate a new request to submit > > Hope this helps. > Christina > > >> >> Please advise on what to change and/or look for. I can also send >> logs and/or config files if that would help. >> >> Best Regards, >> -Emily >> >> >> >> >> _______________________________________________ >> 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 Emily at arcananet.com Fri Apr 10 23:02:37 2015 From: Emily at arcananet.com (Emily Stemmerich) Date: Fri, 10 Apr 2015 23:02:37 +0000 Subject: [Pki-users] Router identity certificate auto-renewal questions In-Reply-To: <55284875.7050903@redhat.com> References: <5527F6EA.2020502@redhat.com> <55284875.7050903@redhat.com> Message-ID: Thanks Christina, Looks like I will need to figure out directory auth for the routers instead of the one-time flatfile since the routers need to be able to auto-renew their identities prior to expiration, otherwise their VPN connections will drop. Do you have any quick links to using directory-based auth for certificate profiles? Unfortunately I can?t do any clock manipulation for testing since that would break things working on the Cisco router ? ntp clock synchronization is a requirement. Any additional advise or information on this is welcome. Thanks, -Emily From: Christina Fu > Date: Friday, April 10, 2015 at 3:02 PM To: "pki-users at redhat.com" > Subject: Re: [Pki-users] Router identity certificate auto-renewal questions reposting, since I Emily possibly joined the mailing list after I replied ;-). Christina On 04/10/2015 09:14 AM, Christina Fu wrote: Hi Emily, Please see my in-line reply below. Actually, you might want to read my last comment first, and then circle back, so you won't get confused. Christina On 04/08/2015 02:38 PM, Emily Stemmerich wrote: Hi, I was referred to this email list by alee on the #dogtag-pki IRC group to get some help on automatic certificate renewals. We are trying to get Dogtag 10.2.1 set up to be a certificate authority for Cisco routers? identity certificates. For the first step I have things working to get a certificate using the caRouterCert.cfg profile with a one-time password in the flatfile.txt. For the second step I?m trying to get auto-renewal of the identity certificates working. Here is where I stand: If you intend to do auto-enrollment, then one-time pin is not the right authentication method. See my reply to #2 below. 1. For testing, I have set the validity to 1 day so that the renewal attempt happens the next day? I don?t see a way of making it any shorter to expedite testing. a trick I hear in testing is to reset the clock 2. I have added ?renewal=true? to the caRouterCert.cfg hoping that it will enable auto-renewal. I?m not sure if using the same profile would require that a ?one-time? password needs to be in flatfile.txt again (which isn?t practical)? If I would need a different profile for the renewal I?m not clear on how to add and then use it for the renewal. the caRouterCert profile works just like all the other profiles where the authentication/authorization are configurable. Here is a link that explains how authentication works and how to configure in profiles: https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Authentication_for_Enrolling_Certificates.html You have choices of authentication. For example, if you want auto-approval (without agent manual approval), you will need to set up directory-based authentication. 3. I have renewal.graceBefore=10 and renewal.graceAfter=1 in the profile just for testing purposes. 4. I have confirmed on the router that the expiration is as expected (24hrs) and it shows a date/time that it will attempt to renew automatically (the link below discusses cert renewal from the perspective of IOS). http://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/116094-maintain-ios-pki.html#anc8 5. When the renewal time comes on the router, I see lots of activity in the dogtag debug log, but am unsure of what to look for to troubleshoot it failing. Please note that the renewal feature is not intended for the router. You can read the doc here: https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Renewing_Certificates.html In case of router renewal, you just need to go through the same caRouterCert profile. As you can see from the renewal link above, renewal can take two forms: 1. reuse keys - in this case, you just need to resubmit the same request 2. new keys - in this case, you generate a new request to submit Hope this helps. Christina Please advise on what to change and/or look for. I can also send logs and/or config files if that would help. Best Regards, -Emily _______________________________________________ Pki-users mailing list Pki-users at redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users _______________________________________________ Pki-users mailing list Pki-users at redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Fri Apr 10 23:14:03 2015 From: cfu at redhat.com (Christina Fu) Date: Fri, 10 Apr 2015 16:14:03 -0700 Subject: [Pki-users] Router identity certificate auto-renewal questions In-Reply-To: References: <5527F6EA.2020502@redhat.com> <55284875.7050903@redhat.com> Message-ID: <5528593B.3060300@redhat.com> https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Automated_Enrollment.html#Setting_up_Directory_Based_Authentication On 04/10/2015 04:02 PM, Emily Stemmerich wrote: > Thanks Christina, > > Looks like I will need to figure out directory auth for the routers > instead of the one-time flatfile since the routers need to be able to > auto-renew their identities prior to expiration, otherwise their VPN > connections will drop. Do you have any quick links to using > directory-based auth for certificate profiles? > > Unfortunately I can't do any clock manipulation for testing since that > would break things working on the Cisco router -- ntp clock > synchronization is a requirement. > > Any additional advise or information on this is welcome. > > Thanks, > -Emily > > From: Christina Fu > > Date: Friday, April 10, 2015 at 3:02 PM > To: "pki-users at redhat.com " > > > Subject: Re: [Pki-users] Router identity certificate auto-renewal > questions > > reposting, since I Emily possibly joined the mailing list after I > replied ;-). > > Christina > > On 04/10/2015 09:14 AM, Christina Fu wrote: >> Hi Emily, >> Please see my in-line reply below. >> Actually, you might want to read my last comment first, and then >> circle back, so you won't get confused. >> >> Christina >> >> On 04/08/2015 02:38 PM, Emily Stemmerich wrote: >>> Hi, >>> >>> I was referred to this email list by alee on the #dogtag-pki IRC >>> group to get some help on automatic certificate renewals. We are >>> trying to get Dogtag 10.2.1 set up to be a certificate authority for >>> Cisco routers' identity certificates. For the first step I have >>> things working to get a certificate using the caRouterCert.cfg >>> profile with a one-time password in the flatfile.txt. For the >>> second step I'm trying to get auto-renewal of the identity >>> certificates working. Here is where I stand: >>> >> If you intend to do auto-enrollment, then one-time pin is not the >> right authentication method. See my reply to #2 below. >> >>> 1. For testing, I have set the validity to 1 day so that the >>> renewal attempt happens the next day... I don't see a way of making >>> it any shorter to expedite testing. >> a trick I hear in testing is to reset the clock >> >>> >>> 2. I have added "renewal=true" to the caRouterCert.cfg hoping that >>> it will enable auto-renewal. I'm not sure if using the same profile >>> would require that a "one-time" password needs to be in flatfile.txt >>> again (which isn't practical)? If I would need a different profile >>> for the renewal I'm not clear on how to add and then use it for the >>> renewal. >> the caRouterCert profile works just like all the other profiles where >> the authentication/authorization are configurable. >> Here is a link that explains how authentication works and how to >> configure in profiles: >> https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Authentication_for_Enrolling_Certificates.html >> >> You have choices of authentication. For example, if you want >> auto-approval (without agent manual approval), you will need to set >> up directory-based authentication. >> >>> >>> 3. I have renewal.graceBefore=10 and renewal.graceAfter=1 in the >>> profile just for testing purposes. >>> >>> 4. I have confirmed on the router that the expiration is as >>> expected (24hrs) and it shows a date/time that it will attempt to >>> renew automatically (the link below discusses cert renewal from the >>> perspective of IOS). >>> http://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/116094-maintain-ios-pki.html#anc8 >>> >>> 5. When the renewal time comes on the router, I see lots of >>> activity in the dogtag debug log, but am unsure of what to look for >>> to troubleshoot it failing. >> >> Please note that the renewal feature is not intended for the router. >> You can read the doc here: >> https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Renewing_Certificates.html >> >> In case of router renewal, you just need to go through the same >> caRouterCert profile. As you can see from the renewal link above, >> renewal can take two forms: >> 1. reuse keys - in this case, you just need to resubmit the same request >> 2. new keys - in this case, you generate a new request to submit >> >> Hope this helps. >> Christina >> >> >>> >>> Please advise on what to change and/or look for. I can also send >>> logs and/or config files if that would help. >>> >>> Best Regards, >>> -Emily >>> >>> >>> >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users >> >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-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 mharmsen at redhat.com Fri Apr 10 23:34:50 2015 From: mharmsen at redhat.com (Matthew Harmsen) Date: Fri, 10 Apr 2015 17:34:50 -0600 Subject: [Pki-users] Check version of dogtag certificate system In-Reply-To: References: <549977482.71922.1428558653963.JavaMail.root@fiscaliatabasco.gob.mx> <55271AC9.3000401@redhat.com> Message-ID: <55285E1A.4050802@redhat.com> On 04/10/15 11:09, Emily Stemmerich wrote: > You can just simply run 'pki --version' to see the version output. > > -Emily > This is fine when run on the machine hosting the server. However, bear in mind that this returns the version of the CLI client tool (which may be installed remotely), not necessarily the CS server. -- Matt > From: Matthew Harmsen > > Date: Thursday, April 9, 2015 at 5:35 PM > To: Ricardo Alexander Alexander Perez Ricardez > >, "pki-users at redhat.com > " > > Subject: Re: [Pki-users] Check version of dogtag certificate system > > On 04/08/15 23:50, Ricardo Alexander Alexander Perez Ricardez wrote: >> Hi, >> >> How to check what version of dogtag certficate system is installed on my system? >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users > Ricardo, > > You can check what version of Dogtag you are running by the RPM > Name-Version-Release (NVR) via the command-line: > > * rpm -qa pki-server > pki-server-10.2.2-0.1.fc21.noarch > > In the above example, a Fedora 21 machine contains Dogtag 10.2.2. > > For the latest Dogtag versions on various platforms, see the following: > > * http://pki.fedoraproject.org/wiki/Dogtag_branches_and_releases > > Thanks, > -- Matt > > > > _______________________________________________ > 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 rperez at fiscaliatabasco.gob.mx Fri Apr 10 23:25:41 2015 From: rperez at fiscaliatabasco.gob.mx (Ricardo Alexander Alexander Perez Ricardez) Date: Fri, 10 Apr 2015 18:25:41 -0500 (CDT) Subject: [Pki-users] Problems with OCSP In-Reply-To: <1772328256.75386.1428708094342.JavaMail.root@fiscaliatabasco.gob.mx> Message-ID: <592681420.75563.1428708341525.JavaMail.root@fiscaliatabasco.gob.mx> How to validate if the OCSP is working correctly on the client side ? I'm using Digital Signatures In Adobe reader, When I enable the option: "Require certificate revocation checking to verify signatures wherever possible" I recieve this message: "OCSP Response Signing invalid" -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firma_ocsp2.PNG Type: image/png Size: 44356 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firma_ocsp.PNG Type: image/png Size: 37317 bytes Desc: not available URL: From steve.neuharth at gmail.com Sat Apr 11 02:19:53 2015 From: steve.neuharth at gmail.com (Steve (st33v) Neuharth) Date: Fri, 10 Apr 2015 21:19:53 -0500 Subject: [Pki-users] getting NEED_TO_NOTIFY_ISSUED_SAVE_FAILED with dogtag-submit In-Reply-To: <20150410132917.GA8197@redhat.com> References: <20150407142523.GD26921@redhat.com> <20150407175619.GI26921@redhat.com> <20150407192236.GJ26921@redhat.com> <20150407195736.GK26921@redhat.com> <20150408213546.GA1294@redhat.com> <20150410132917.GA8197@redhat.com> Message-ID: <757B2FDB-B8CC-47EB-BFD3-4ECB5EE0E210@sylvation.com> > On Apr 10, 2015, at 8:29 AM, Nalin Dahyabhai wrote: > >> Also... when I request a cert using caServerCert and approve it in DogTag, >> the certmonger request sits in CA_WORKING status for a while. How long can >> I expect it to stay that way? > > If the server or helper can advise how long the daemon should wait > before it polls again, it'll be prepend the amount of time to wait, in > seconds, to the output (when using agent creds, the helper advises 0, > for no waiting period) and the exit status will be 5. If it doesn't > have a value to advise (when it doesn't have agent creds), it'll skip > outputting that and will indicate that by using exit status 1. In both > cases, if there's a state value that the helper will need to be passed > the next time it's called, it then outputs that. > > Getting a certificate from dogtag is a multi-step process, and the > helper uses this to have the certmonger daemon run each step separately, > which is intended to make it easier to resume or retry at each > individual step if we hit a connectivity problem or the system gets > rebooted. > >> I've always been impatient and done a *getcert refresh *on the request to >> force a download but is there a configurable poll interval or anything? I >> didn't see anything obvious in the docs. > > Absent any good idea of how quickly or slowly we can expect a manual > approval to happen, the default guess is half of the remaining validity > time if we already have a certificate, or a week, whichever is less, > with a minimum of five minutes. That's not currently configurable, but > the boundaries and the defaults could be made configurable if need be. > > HTH, > > Nalin Thanks for the explanation. This definitely helps me understand the expected cert request workfloe when using certmonger. I was expecting certmonger to poll more actively for certs that it hadn?t yet received but I suppose I can just use `getcert refresh` to force the download when I need to. Have a great weekend! ?steve From nali.mrt at gmail.com Mon Apr 13 16:48:19 2015 From: nali.mrt at gmail.com (Nalinda Herath) Date: Mon, 13 Apr 2015 22:18:19 +0530 Subject: [Pki-users] Problems with OCSP In-Reply-To: <592681420.75563.1428708341525.JavaMail.root@fiscaliatabasco.gob.mx> References: <1772328256.75386.1428708094342.JavaMail.root@fiscaliatabasco.gob.mx> <592681420.75563.1428708341525.JavaMail.root@fiscaliatabasco.gob.mx> Message-ID: Hi Ricardo, Did you try the openssl ocsp verifier commands? https://www.openssl.org/docs/apps/ocsp.html (check the examples at the bottom) Regards, Nalinda On Sat, Apr 11, 2015 at 4:55 AM, Ricardo Alexander Alexander Perez Ricardez wrote: > How to validate if the OCSP is working correctly on the client side ? > > > I'm using Digital Signatures In Adobe reader, When I enable the option: > > *"Require certificate revocation checking to verify signatures wherever > possible"* > > > I recieve this message: > > *"OCSP Response Signing invalid"* > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > -- Best Regards, Nalinda -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firma_ocsp2.PNG Type: image/png Size: 44356 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firma_ocsp.PNG Type: image/png Size: 37317 bytes Desc: not available URL: From ali.elkhalidi at gmail.com Wed Apr 22 09:17:58 2015 From: ali.elkhalidi at gmail.com (Ali Khalidi) Date: Wed, 22 Apr 2015 12:17:58 +0300 Subject: [Pki-users] confused about access control list Message-ID: I've tried a simple example of using the ACL to block profile listing and it works. however, I want to disable a CA agent from submitting/approving or executing any enrollment requests. I've went through all the ACLs, and whenever I encountered a submit right, I flipped to deny. despite that the agent still is able to submit and enroll certificates. another aspect, I was looking into the user_orgreq ACL plugin. can someone provide and an example on how this can be used in the context of ACLs? thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Fri Apr 24 16:31:09 2015 From: cfu at redhat.com (Christina Fu) Date: Fri, 24 Apr 2015 09:31:09 -0700 Subject: [Pki-users] confused about access control list In-Reply-To: References: Message-ID: <553A6FCD.6080507@redhat.com> On 04/22/2015 02:17 AM, Ali Khalidi wrote: > I've tried a simple example of using the ACL to block profile listing > and it works. however, I want to disable a CA agent from > submitting/approving or executing any enrollment requests. I've went > through all the ACLs, and whenever I encountered a submit right, I > flipped to deny. despite that the agent still is able to submit and > enroll certificates. > information on access control can be found here: https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Authorization_for_CRTS_Users.html It would help if you give us an acl example that you tried that does not work? > > another aspect, I was looking into the user_orgreq ACL plugin. can > someone provide and an example on how this can be used in the context > of ACLs? The user_origreq is an access evaluator plugin for the UserOrigReqAccessEvaluator. Its primary purpose is for access control during renewal. It checks to see the the authenticated user and the original request ownership match. Hope this helps. > > thanks, > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Majain at verisign.com Sun Apr 26 13:30:52 2015 From: Majain at verisign.com (Jain, Mahendra) Date: Sun, 26 Apr 2015 13:30:52 +0000 Subject: [Pki-users] Rest API to renew server certificate Message-ID: Hello All, I?m using Dogtag Certificate System to manage certificates. I have successfully submitted the server certificate request and got it approved using following REST APIs: @POST @Path("certrequests") @ClientResponseType(entityType=CertRequestInfos.class) public Response enrollCert(CertEnrollmentRequest data); @POST @Path("agent/certrequests/{id}/approve") @ClientResponseType(entityType=Void.class) @ACLMapping("certrequests") @AuthMethodMapping("certrequests") public Response approveRequest(@PathParam("id") RequestId id, CertReviewResponse data); While I can renew the server certificate via Web interface, I did not find any REST API to renew the server cert. Do I need to submit certificate enrollment request again with original CSR and set the renewal flag to true? Since I already have certificate serial number, is there a REST API to renew server cert using serial number alone? Thanks, Mahendra ?This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Mon Apr 27 22:06:48 2015 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Mon, 27 Apr 2015 22:06:48 +0000 Subject: [Pki-users] US Government SmartCard question Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7C7EAF@001FSN2MPN1-046.001f.mgd2.msft.net> Hi, I'm trying to set up smart card logins on Linux using a clean Fedora 21 install following the instructions at [1]. My main objective is to use my USDA-issued LincPass (the USDA brand of the USAccess card) for login to local accounts on linux machines that are not joined to the domain and which are outside the firewall. Essentially, I have control over a handful of machines, but no control over issuing the smart cards. I'll try to get you relevant debugging info, but I don't know much about smart card internals. My setup (card info from ActivClient on Windows): Card Reader: SCR3310 v2.0 "smartOS powered" Smart Card Mfr: Oberthur Technologies Smart Card Model: ID-One Cosmo v7.0 with Oberthur PIV Applet Suite 2.3.2 The problem: following instructions at [1], "pkcs11_inspect debug" results in "no token available" and the light on the reader never comes on. Googling, I saw that US government cards may require CACKey instead of coolkey, so I downloaded/compiled/installed the version at [2] and modified the pam_pkcs11.conf file. Reboot. Improvement. The light comes on. Repeating the "pkcs11_inspect debug" prompts for a PIN for token, and fails immediately afterward with "pkcs11_pass_login() failed: pkcs11_login() failed". I entered the PIN I enter on Windows. Any insights are appreciated. Thanks, Bryce [1] https://docs.fedoraproject.org/en-US/Fedora/19/html/Security_Guide/sect-Security_Guide-Single_Sign_on_SSO-Getting_Started_with_your_new_Smart_Card.html [2] https://github.com/Conservatory/CACKey -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Mon Apr 27 22:33:03 2015 From: jmagne at redhat.com (John Magne) Date: Mon, 27 Apr 2015 18:33:03 -0400 (EDT) Subject: [Pki-users] US Government SmartCard question In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7C7EAF@001FSN2MPN1-046.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7C7EAF@001FSN2MPN1-046.001f.mgd2.msft.net> Message-ID: <834675460.8866831.1430173983543.JavaMail.zimbra@redhat.com> The coolkey pkcs#11 module should provide enough functionality for smart card login with CAC cards. I know there is plenty of code in the coolkey driver to handle CACs. Of course your particular card could be some special case I'm not aware of. There are a few things that could be wrong. 1. Check to make sure the "psc-lite" daemon is running. 2. There might be an issue with your reader. For instance the ccid driver sometimes needs to be configured to allow for readers that require a higher voltage such as the omnikey. One thing to try, with coolkey and your card and reader. 1. Kill pcscd as root. 2. run it manually such that it throws log messages to the console /usr/sbin/pcscd -f -d -a. 3. Insert the card , watch the logs for any suspicious messages which might provide a clue. If the log says the card is being recognized, then we could possible get some coolkey logs when you attempt that pkcs11 command mentioned earlier. thanks, jack ----- Original Message ----- > From: "Bryce L Nordgren -FS" > To: pki-users at redhat.com > Sent: Monday, April 27, 2015 3:06:48 PM > Subject: [Pki-users] US Government SmartCard question > > > > Hi, > > > > I?m trying to set up smart card logins on Linux using a clean Fedora 21 > install following the instructions at [1]. My main objective is to use my > USDA-issued LincPass (the USDA brand of the USAccess card) for login to > local accounts on linux machines that are not joined to the domain and which > are outside the firewall. Essentially, I have control over a handful of > machines, but no control over issuing the smart cards. > > > > I?ll try to get you relevant debugging info, but I don?t know much about > smart card internals. My setup (card info from ActivClient on Windows): > > > > Card Reader: SCR3310 v2.0 ?smartOS powered? > > Smart Card Mfr: Oberthur Technologies > > Smart Card Model: ID-One Cosmo v7.0 with Oberthur PIV Applet Suite 2.3.2 > > > > The problem: following instructions at [1], ?pkcs11_inspect debug? results in > ?no token available? and the light on the reader never comes on. Googling, I > saw that US government cards may require CACKey instead of coolkey, so I > downloaded/compiled/installed the version at [2] and modified the > pam_pkcs11.conf file. Reboot. Improvement. The light comes on. Repeating the > ?pkcs11_inspect debug? prompts for a PIN for token, and fails immediately > afterward with ?pkcs11_pass_login() failed: pkcs11_login() failed?. I > entered the PIN I enter on Windows. > > > > Any insights are appreciated. > > > > Thanks, > > Bryce > > > > > > [1] > https://docs.fedoraproject.org/en-US/Fedora/19/html/Security_Guide/sect-Security_Guide-Single_Sign_on_SSO-Getting_Started_with_your_new_Smart_Card.html > > [2] https://github.com/Conservatory/CACKey > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From Emily at arcananet.com Mon Apr 27 23:53:43 2015 From: Emily at arcananet.com (Emily Stemmerich) Date: Mon, 27 Apr 2015 23:53:43 +0000 Subject: [Pki-users] SCEP directory authentication Message-ID: Hi, I am still trying to get Dogtag 10.2.1 on Fedora 21 working to allow for router identity certificates obtained by Cisco Routers via SCEP to be auto-renewing. I have found that the one-time pin model doesn?t work for auto-renewal. I was pointed to the RedHat document below that discusses using directory-based auth in Section 8.2.1, but I?m having issues with getting it to work. https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Automated_Enrollment.html#Setting_up_Directory_Based_Authentication I?m not certain what to put in the dnpattern attribute and there are no examples I can find and am wondering if it is the reason attempts show uid and credentials as null from the router ? details of the setup later on in this email. * dnpattern. Specifies a string representing a subject name pattern to formulate from the directory attributes and entry DN. ------------------------------------------ >From my CS.conf (RouterAuth is then referenced in the caRouterCert.cfg instead of flatfile): auths.instance.RouterAuth.pluginName=UidPwdDirAuth auths.instance.RouterAuth.ldap.basedn=ou=RouterID,dc=auth,dc=sample,dc=com auths.instance.RouterAuth.ldap.ldapconn.host=localhost auths.instance.RouterAuth.ldap.ldapconn.port=389 auths.instance.RouterAuth.ldap.ldapconn.secureConn=false ------------------------------------------ I?ve created a hierarchy outside of dogtag for doing router auth: ou=RouterID,dc=auth,dc=sample,dc=com ------------------------------------------ Test User Account (I am not sure what objectClass to use, so I found one with uid and password as options and used that): dn: uid=172.18.240.11,ou=RouterID,dc=auth,dc=sample,dc=com uid: 172.18.240.11 objectClass: inetUser userPassword: testpass ------------------------------------------ Router config. For flatfile auth it ends up using the wan IP and the password and password in the identity section, however for LDAP auth I don?t know what things would map to: crypto ca identity SAMPLE enrollment url http://172.21.4.239:8080/ca/cgi-bin revocation-check none fqdn emilyvpn.sample.com serial-number none ip-address none hash sha256 password testpass rsakeypair MEVO 2048 auto-enroll 75 crl optional exit crypto ca authenticate SAMPLE ------------------------------------------ When I try and get a cert from the Cisco Router I get output like the following in the debug file that lists both UID and credential as null: [24/Apr/2015:16:31:18][http-bio-8080-exec-7]: Got authenticator=com.netscape.cms.authentication.UidPwdDirAuthentication [24/Apr/2015:16:31:18][http-bio-8080-exec-7]: LdapAnonConnFactory::getConn [24/Apr/2015:16:31:18][http-bio-8080-exec-7]: LdapAnonConnFactory.getConn(): num avail conns now 4 [24/Apr/2015:16:31:18][http-bio-8080-exec-7]: Authenticating UID=null [24/Apr/2015:16:31:19][http-bio-8080-exec-7]: returnConn: mNumConns now 4 [24/Apr/2015:16:31:19][http-bio-8080-exec-7]: operation failure - Authentication credential for uid is null. [24/Apr/2015:16:31:19][http-bio-8080-exec-7]: Output PKIOperation response: Thanks for any assistance, -Emily -------------- next part -------------- An HTML attachment was scrubbed... URL: From techpkiuser at gmail.com Tue Apr 28 05:49:56 2015 From: techpkiuser at gmail.com (Kamal Perera) Date: Tue, 28 Apr 2015 11:19:56 +0530 Subject: [Pki-users] renew expired admin certificate Message-ID: Dear All, I'm in the process of regaining one of the old CA systems which was not being used for a long time. In the root CA, administrator certificate is expired and cannot access the agent interface. In order to renew it, i would need the access to the agent interface. Please help me to proceed with the login in to the agent interface. Regards, Kamal -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Wed Apr 29 16:59:41 2015 From: cfu at redhat.com (Christina Fu) Date: Wed, 29 Apr 2015 09:59:41 -0700 Subject: [Pki-users] confused about access control list In-Reply-To: References: <553A6FCD.6080507@redhat.com> Message-ID: <55410DFD.9010602@redhat.com> Hi, I was looking for an exact aci syntax example you tried that failed so I could help you better with. Did you do something like: resourceACLS: certServer.ee.request.enrollment:submit:allow (submit) user!="someBody" && group="Agents":All Agents other than someBody may submit an enrollment request I got the syntax info from the link I gave you. Let me know if that's what you tried. Christina On 04/24/2015 11:14 AM, Ali Khalidi wrote: > In my test, I've added an user to CM and assigned him Agent group > permissions. > now, I want to deny this user enrollment submission, so there are two > default and pre-existing ACLs of relevance: > certServer.ca.request.enrollment and certServer.ee.request.enrollment > in both I tried the following to the submit right: > change the submit right from allow to deny -> the user can still > submit and enroll a certificate > change back to allow, then added a deny rule with the username > specified -> the user can still submit and enroll a certificate > > these were just experiments to understand how ACLs work. > > my end goal, if possible with dogtag, and I would appreciate if you > point me to the right direction is: > restrict an agent to submit and execute and enrollment based on a > specific certificate profile. > > having said the latter, the user_origreq looked promising for that > matter, but I have no clue how to create a new ACL with it. help is > appreciated in the area as well. > > > Thanks, > > Ali > > > > > > > > On Fri, Apr 24, 2015 at 7:31 PM, Christina Fu > wrote: > > > On 04/22/2015 02:17 AM, Ali Khalidi wrote: >> I've tried a simple example of using the ACL to block profile >> listing and it works. however, I want to disable a CA agent from >> submitting/approving or executing any enrollment requests. I've >> went through all the ACLs, and whenever I encountered a submit >> right, I flipped to deny. despite that the agent still is able to >> submit and enroll certificates. >> > information on access control can be found here: > https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Authorization_for_CRTS_Users.html > > It would help if you give us an acl example that you tried that > does not work? > >> >> another aspect, I was looking into the user_orgreq ACL plugin. >> can someone provide and an example on how this can be used in the >> context of ACLs? > > The user_origreq is an access evaluator plugin for the > UserOrigReqAccessEvaluator. Its primary purpose is for access > control during renewal. It checks to see the the authenticated > user and the original request ownership match. > > Hope this helps. > >> >> thanks, >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Thu Apr 30 22:22:50 2015 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Thu, 30 Apr 2015 22:22:50 +0000 Subject: [Pki-users] US Government SmartCard question In-Reply-To: <834675460.8866831.1430173983543.JavaMail.zimbra@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E7C7EAF@001FSN2MPN1-046.001f.mgd2.msft.net> <834675460.8866831.1430173983543.JavaMail.zimbra@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7CA9C1@001FSN2MPN1-046.001f.mgd2.msft.net> Hi Jack, thanks for the reply! AFAIK, my card is the same as all other cards issued by USDA, and I suspect the same as all other cards issued by the US Government. It's not a test card or anything. I killed pcscd and ran it on the command line to capture logs (attached). I didn't see anything which set off red flags for me. It looks like it's detecting card insertion and removal events. I'm including the output of "pkcs11_inspect debug", run both as my user account and as root via sudo. All of this was done with coolkey. The cackey module in /etc/pam_pkcs11/pam_pkcs11.conf was commented out. The only real difference between now and previously is that now the light comes on. (Still fails with no token available, tho.) I'm just not seeing anything that points me at a solution. Hope you can intuit more from this. Bryce > -----Original Message----- > From: John Magne [mailto:jmagne at redhat.com] > Sent: Monday, April 27, 2015 4:33 PM > To: Nordgren, Bryce L -FS > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] US Government SmartCard question > > The coolkey pkcs#11 module should provide enough functionality for smart > card login with CAC cards. > I know there is plenty of code in the coolkey driver to handle CACs. Of course > your particular card could be some special case I'm not aware of. > > There are a few things that could be wrong. > > 1. Check to make sure the "psc-lite" daemon is running. > > 2. There might be an issue with your reader. For instance the ccid driver > sometimes needs to be configured to allow for readers that require a higher > voltage such as the omnikey. > > > One thing to try, with coolkey and your card and reader. > > 1. Kill pcscd as root. > > 2. run it manually such that it throws log messages to the console > > /usr/sbin/pcscd -f -d -a. > > 3. Insert the card , watch the logs for any suspicious messages which might > provide a clue. > > If the log says the card is being recognized, then we could possible get some > coolkey logs when you attempt that pkcs11 command mentioned earlier. > > thanks, > jack > > > > ----- Original Message ----- > > From: "Bryce L Nordgren -FS" > > To: pki-users at redhat.com > > Sent: Monday, April 27, 2015 3:06:48 PM > > Subject: [Pki-users] US Government SmartCard question > > > > > > > > Hi, > > > > > > > > I?m trying to set up smart card logins on Linux using a clean Fedora > > 21 install following the instructions at [1]. My main objective is to > > use my USDA-issued LincPass (the USDA brand of the USAccess card) for > > login to local accounts on linux machines that are not joined to the > > domain and which are outside the firewall. Essentially, I have control > > over a handful of machines, but no control over issuing the smart cards. > > > > > > > > I?ll try to get you relevant debugging info, but I don?t know much > > about smart card internals. My setup (card info from ActivClient on > Windows): > > > > > > > > Card Reader: SCR3310 v2.0 ?smartOS powered? > > > > Smart Card Mfr: Oberthur Technologies > > > > Smart Card Model: ID-One Cosmo v7.0 with Oberthur PIV Applet Suite > > 2.3.2 > > > > > > > > The problem: following instructions at [1], ?pkcs11_inspect debug? > > results in ?no token available? and the light on the reader never > > comes on. Googling, I saw that US government cards may require CACKey > > instead of coolkey, so I downloaded/compiled/installed the version at > > [2] and modified the pam_pkcs11.conf file. Reboot. Improvement. The > > light comes on. Repeating the ?pkcs11_inspect debug? prompts for a PIN > > for token, and fails immediately afterward with ?pkcs11_pass_login() > > failed: pkcs11_login() failed?. I entered the PIN I enter on Windows. > > > > > > > > Any insights are appreciated. > > > > > > > > Thanks, > > > > Bryce > > > > > > > > > > > > [1] > > https://docs.fedoraproject.org/en- > US/Fedora/19/html/Security_Guide/sec > > t-Security_Guide-Single_Sign_on_SSO- > Getting_Started_with_your_new_Smar > > t_Card.html > > > > [2] https://github.com/Conservatory/CACKey > > > > _______________________________________________ > > Pki-users mailing list > > Pki-users at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- A non-text attachment was scrubbed... Name: pcscd.log Type: application/octet-stream Size: 14682 bytes Desc: pcscd.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pkcs11_debug.log Type: application/octet-stream Size: 1399 bytes Desc: pkcs11_debug.log URL: