yes, the certificate in the request file has a newline after the certificate data:

cert=-----BEGIN CERTIFICATE-----
...cert data...
                                                    <---- extra newline

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.

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

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.