If a CSR has a set of extensions, but the CSR contains attributes other than the extensions python-nss will fail to find the extensions in the CSR. Background: A CSR in addition to the subject and public key can also contain a set of attributes that provide further information for the CA. Each type of attribute is encoded separately as one member of the attribute set. Each attribute contains a set of values. One of the most common attributes found in a CSR is the PKCS #9 extension requests, a set of certificate extensions which is to be encoded in the final cert issued by the CA. However, that is not the only possible attribute type which can appear, it just happens to be the most common. NSS provides the CERT_GetCertificateRequestExtensions function to extract the extensions from a CSR. Unfortunately NSS hardcoded CERT_GetCertificateRequestExtensions to expect the extensions attribute will be the first attribute in the set of attributes in the CSR. That assumption is not valid, it works in the majority case but correct for all cases. python-nss used the NSS function CERT_GetCertificateRequestExtensions to extract the extensions from a CSR. Therefore when python-nss was provided with a CSR that contained a FriendlyName attribute as the first attribute in the CSR and the extensions as the second attribute python-nss failed to locate and return the extensions in the CSR.
A fix for python-nss has been developed. Rather than calling CERT_GetCertificateRequestExtensions it iterates over the set of attributes searching for any extension attributes. At the same time it was observed that the CertificateRequest class in python-nss did not expose the set of attributes, only the set of extensions. This omission has also been fixed, this is now a CertAttribute class and the CertificateRequest.attributes property now returns a tuple of CertAttribute objects. This allows full access to all attributes and their values. The CertificateRequest.extensions property remains as it was, it returns a tuple of CertificateExtensions. The only change with the extensions property is that it now is populated correctly, even in the presence of other attributes. A bug has been filed with upstream NSS regarding CERT_GetCertificateRequestExtensions https://bugzilla.mozilla.org/show_bug.cgi?id=966319 python-nss is NOT dependent upon NSS fixing CERT_GetCertificateRequestExtensions. A new unit test was added to python-nss to test decoding a CSR, it's located in test/test_cert_request.py The unit test illustrates how one can access the CSR attributes, all their values, and the extensions. One now has access to every piece of data in the CSR.
Forgot to mention an important point. CSR's with a FriendlyName attribute as the first attribute are produced by certmonger, therefore this problem shows up frequently in IPA deployments and with certmonger being considered for deployment in OpenStack it's likely to show up as an OpenStack issue as well.
Created attachment 857958 [details] simple python program with problematic CSR
Created attachment 857959 [details] output from example program
python-nss-0.15.0-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/python-nss-0.15.0-1.fc20
Package python-nss-0.15.0-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing python-nss-0.15.0-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-7306/python-nss-0.15.0-1.fc20 then log in and leave karma (feedback).
python-nss-0.15.0-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.