Hide Forgot
Steps to reproduce: This problem sporadically occurs in 'certutil' when using the "-a" option. The Dogtag Certificate System utilizes the following 'certutil' commands to generate a certificate: * certutil -N -d /tmp/ztest/certs -f /tmp/ztest/password.conf * certutil -A -n "caadmin" -t "u,u,u" -f /tmp/ztest/password.conf -d /tmp/ztest/certs -a -i /tmp/ztest/ca_admin.cert Actual results: It has been noticed that occasionally, the following command sequence utilized to generate a certificate fails: * certutil -N -d /tmp/ztest/certs -f /tmp/ztest/password.conf * certutil -A -n "caadmin" -t "u,u,u" -f /tmp/ztest/password.conf -d /tmp/ztest/certs -a -i /tmp/ztest/ca_admin.cert error converting ascii to binary (Unrecognized Object Identifier.) certutil: unable to read input file: Unrecognized Object Identifier. Here is a sample of a failed ASCII certificate request: MIID9DCCAtygAwIBAgIBBjANBgkqhkiG9w0BAQsFADA+MRswGQYDVQQKExJVU0VS U1lTLlJFREhBVC5DT00xHzAdBgNVBAMTFkNBIFNpZ25pbmcgQ2VydGlmaWNhdGUw HhcNMTIxMDI1MjMyODU1WhcNMTQxMDE1MjMyODU1WjCBkzEbMBkGA1UEChMSVVNF UlNZUy5SRURIQVQuQ09NMSkwJwYJKoZIhvcNAQkBFhpjYWFkbWluQHVzZXJzeXMu cmVkaGF0LmNvbTEXMBUGCgmSJomT8ixkAQETB2NhYWRtaW4xMDAuBgNVBAMTJ0NB IEFkbWluaXN0cmF0b3Igb2YgSW5zdGFuY2UgcGtpLXRvbWNhdDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALz/yuUqY4oDtz/jktdrquoHItGj01w9l3BJ 8mfhmnFR9L1n7Coh4opBaJ/cVo11craeblOhq9pYrSrd6HWKsF26n1dGOGcW80kF pnbRIl/nvohPEv70T/jG2Mau0OrmIPyofeggKlfqq5ZE+E/WR6DKuACmCVDIbfg4 /i34fMCL/kWKfgwwht2jRVjbHgRGF7HCDLbxR4unqMG9CAEC/oHNgD3y5BZmw8nI xdUfxLoonD7DFFPTd3lTSweSNPQTlHOSYRkBbM9qpP2F3XNBkW0rq2o7Sp9gfcCI 7m2RL1C8G/GXafPkLt1NZ3A/zKlrmfnL+Kh1iCES5fDO+KXZVtkCAwEAAaOBpjCB ozAfBgNVHSMEGDAWgBTnj55EvB9WfBzsy/q5r5tvUOUirTBRBggrBgEFBQcBAQRF MEMwQQYIKwYBBQUHMAGGNWh0dHA6Ly9kb2d0YWcxNy1jbG9uZS51c2Vyc3lzLnJl ZGhhdC5jb206ODA4MC9jYS9vY3NwMA4GA1UdDwEB/wQEAwIE8DAdBgNVHSUEFjAU BggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAKgZTBj5P01i AIV/xe12nT7ti4Hz6//yZbwnIWv1tOSCVULsHYzwDSLp0/HRmdux6nKiE8WBtZ59 NHi5ukT1ceNp9iJP2MP7Xx38K3PPhJfkri4ajuSWtQonjyILxvYY9bmPOgCwEKng GWec1pqn73n/Pqe/kQn42w8DOfnyA+JS+xsZi6QdZoy9iKKUUnrsJK/SMoprpbKc fANaeTsKcbA7COYCKUP8W3pMhWDw1DMlFF9o4EnzqYMTw9QfpzJNX8gR+BODaXeI A5Pbv1/UjvQn/8NUGZ99AuPrkBu1FZOnakz6Ln9rnk+2xrFMzh/FJ5CuUy6y91Zl yHiL701M/Io= Expected results: After using the Dogtag Certificate System AtoB tool to change it from ASCII to Binary, I re-ran certutil (without the '-a' option), and it worked fine: AtoB ca_admin.cert ca_bin.cert certutil -A -n "caadmin" -t "u,u,u" -f /tmp/ztest/password.conf -d /tmp/ztest/certs -i /tmp/ztest/ca_bin.cert
Hi, the bug is in function SECU_ReadDERFromFile. It reads the certificate file into a buffer and then passes the buffer unmodified to ATOB_ConvertAsciiToItem if the certificate file is ASCII without PEM header and trailer. ATOB_ConvertAsciiToItem uses PORT_Strlen to determine the length of the buffer, which is wrong in this case, because the buffer is not null-terminated. The buffer and the incorrect length are then passed to NSSBase64_DecodeBuffer, which in turn tries to decode characters past the end of the buffer, which causes the failure described in this bug.
We are hitting this issue again on during our Fedora 19 Test Days (https://fedoraproject.org/wiki/Test_Day:2013-04-18). What are your plans on addressing it? Jan already provided an exact spot in the source code - this should help fixing it.
Thanks to Jan for pointing us to the issue. Somehow I had not seen it yet. Working on a patch now...
I've attached a patch to the upstream bug. Elio, once we have review upstream, we should submit updated packages of NSS for Fedora 18 + 19 (at least).
I've submitted a F19 scratch build with the patch applied. Could you please test it (will probably take 1-2 hours until the build is done)? http://koji.fedoraproject.org/koji/taskinfo?taskID=5270773 (It should be sufficient to install the nss-tools package only.)
fixed my issue. I'm no longer seeing the issue from bug 953485 Is there somewhere I can go give this karma to get it pushed through? Or is it just going to go through auto-magically? Thank!
(In reply to comment #6) > > Is there somewhere I can go give this karma to get it pushed through? Not yet. Waiting for upstream review, then we can do a regular build for Fedora, then you'll see an automatic comment appearing in this bug (about a package being ready for testing), then your karma will be appreciated. Thanks
As another data point, I'm still seeing the install failure with the test build. certutil: could not decode certificate: security library: improperly formatted DER-encoded message.
Created attachment 737727 [details] cert that demonstrates the problem # rpm -q nss nss-3.14.3-11.fc19.test.808217.1.x86_64 # certutil -N -d /tmp/db # certutil -d /tmp/db -A -t u,u,u -n ipaCert -a -i /tmp/testcert
Thank you for the test case. I identified another bug in function SECITEM_ReallocItem...
Another scratch build that fixes the second bug, too: http://koji.fedoraproject.org/koji/taskinfo?taskID=5278092
Created attachment 737769 [details] Failling with build 2 as well Attaching the latest cert # rpm -q nss nss-3.14.3-11.fc19.test.808217.2.x86_64 # certutil -d /tmp/db -A -t u,u,u -n ipaCert -a -i /tmp/testcert2 certutil: could not decode certificate: security library: improperly formatted DER-encoded message.
The previous scratch build didn't work, because my fix was in a shared library that is contained in the nss-util package - which I had forgotten to build for you. But in the meantime, Bob has asked for a different approach to fix the bug - which cannot be backported to NSS 3.14.3. So, for the short term, I will give you a workaround patch, where the fix is contained in the tool code, only. I've started another scratch build with that newer fix. http://koji.fedoraproject.org/koji/taskinfo?taskID=5278741 Again, it's only the nss and nss-tools package, but this time it should be sufficient. (For some reason I cannot reproduce the bug in my Fedora 19 VM, although I am able to reproduce on my primary F18 system. It probably depends on the dynamic contents of memory, it doesn't crash if your runtime memory happens to be fresh and initialized with zeroes...)
Using this build I was able to use certutil and the previous test certs standalone and do a full IPA installation as well.
nss-3.14.3-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/nss-3.14.3-2.fc18
nss-3.14.3-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/nss-3.14.3-2.fc17
nss-3.14.3-12.0.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/nss-3.14.3-12.0.fc19
(In reply to comment #14) > Using this build I was able to use certutil and the previous test certs > standalone and do a full IPA installation as well. Great, thanks for testing Rob! Please give Karma to get the packages into the regular updates.
Package nss-3.14.3-12.0.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nss-3.14.3-12.0.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-6247/nss-3.14.3-12.0.fc19 then log in and leave karma (feedback).
nss-3.14.3-12.0.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
nss-3.14.3-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Once we submit NSS 3.15 packages (very soon), it would be great to get help from QA to re-test. The reason is, the patch used for 3.14 is different than the patch that has been accepted for the main line of 3.15 development. Thanks in advance.
nss-3.14.3-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.