1:53 p.m.
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
<https://dogtag.test.org:8443/ca/ee/ca> -A
https://dogtag.test.org:8443/ca/agent/ca
<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 <http://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
3:35 p.m.
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 <steve(a)sylvation.com> 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
<https://dogtag.test.org:8443/ca/ee/ca> -A
https://dogtag.test.org:8443/ca/agent/ca
<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 <http://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
9:25 a.m.
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
12:18 p.m.
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 <nalin(a)redhat.com> 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
12:56 p.m.
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
1:58 p.m.
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
<https://dogtag.test.org:8443/ca/ee/ca> -A
https://dogtag.test.org:8443/ca/agent/ca
<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
<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
<https://dogtag.test.org:8443/ca/ee/ca/profileSubmit?profileId=caAgentServ...
--pass password --cacert /tmp/test/ca.crt --key /tmp/test/key.pem --cert
/tmp/test/client.pem*
I get a valid response.
*<?xml version="1.0" encoding="UTF-8"
standalone="no"?><XMLResponse><Status>0</Status><Requests><Request><Id>57</Id><SubjectDN>CN=r509
CA,C=US,ST=Minnesota,L=Minneapolis,OU=r509 Intermediate CA,O=Test
Corporation</SubjectDN><serialno>2e</serialno><b64>MIIE0DCCA7igAwIBAgIBLjANBgkqhkiG9w0BAQsFADBEMSEwHwYDVQQKDBh0ZXN0Lm9yZyBTZWN1cml0eSBEb21haW*
*cert data........*
*LP15bCE6K5hABEUfrmZiLJvjBQjFx67Bs0vBaDDb1lqJ8pyjzFHhXtDx5g+/YOzzKqoRdN</b64></Request></Requests></XMLResponse>*
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 <nalin(a)redhat.com> 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
2:22 p.m.
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
<https://dogtag.test.org:8443/ca/ee/ca> -A
https://dogtag.test.org:8443/ca/agent/ca
<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
<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
2:37 p.m.
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
<http://test.org> localKeyID: 4F E5 46 3D foo 64 1F
E4subject=/O=test.org <http://test.org> Security
Domain/emailAddress=caadmin(a)test.org/CN=PKI
<http://caadmin@test.org/CN=PKI> Administratorissuer=/O=test.org
<http://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 <nalin(a)redhat.com> 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
> <https://dogtag.test.org:8443/ca/ee/ca> -A
> https://dogtag.test.org:8443/ca/agent/ca
> <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
> <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=caAgentServ...
> --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
2:57 p.m.
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
<http://test.org> localKeyID: 4F E5 46 3D foo 64 1F
E4subject=/O=test.org <http://test.org> Security
Domain/emailAddress=caadmin(a)test.org/CN=PKI
<http://caadmin@test.org/CN=PKI> Administratorissuer=/O=test.org
<http://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
9:35 a.m.
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 = "<?xml version="1.0"
encoding="UTF-8"
standalone="no"?><XMLResponse><Status>2</Status><Error>Request
Deferred -
{0}</Error><RequestId> 70</RequestId></XMLResponse>"
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 <nalin(a)redhat.com> 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
> <http://test.org> localKeyID: 4F E5 46 3D foo 64 1F
> E4subject=/O=test.org <http://test.org> Security
> Domain/emailAddress=caadmin(a)test.org/CN=PKI
> <http://caadmin@test.org/CN=PKI> Administratorissuer=/O=test.org
> <http://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
4:35 p.m.
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 = "<?xml version="1.0"
encoding="UTF-8"
standalone="no"?><XMLResponse><Status>2</Status><Error>Request
Deferred -
{0}</Error><RequestId> 70</RequestId></XMLResponse>"
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
7:44 a.m.
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 <nalin(a)redhat.com> 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 = "<?xml version="1.0"
encoding="UTF-8"
>
standalone="no"?><XMLResponse><Status>2</Status><Error>Request
Deferred -
> {0}</Error><RequestId> 70</RequestId></XMLResponse>"
> 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
8:29 a.m.
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
9:19 p.m.
On Apr 10, 2015, at 8:29 AM, Nalin Dahyabhai <nalin(a)redhat.com>
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
3542
days inactive
3549
days old
13 comments
3 participants
participants (3)
-
Nalin Dahyabhai -
Steve (st33v) Neuharth -
Steve Neuharth