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