]$ openssl req -new -x509 -days 3650 -out privkey.pem Generating a 2048 bit RSA private key ......................................+++ .....+++ writing new private key to 'privkey.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:GB State or Province Name (full name) []: Locality Name (eg, city) [Default City]: Organization Name (eg, company) [Default Company Ltd]: Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []: Email Address []: [dwoodhou@i7 ~]$ [dwoodhou@i7 ~]$ cat privkey.pem -----BEGIN ENCRYPTED PRIVATE KEY----- MIIFDjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQIXhz86qWarMwCAggA MBQGCCqGSIb3DQMHBAilQCqRhoYkYgSCBMjxH8veSZmD/nKndUEJ9uERdtT5h8OV vEd9EX0HtKLyr86o5zEWfqC73x+riEi+L5MhUzHwEEC3ZAjVpNcv727Yb45FUJgs cDJxSKC0sk6FMmY2yUKbe+dWzs59HuWqVC+0c6wOSdBg8cQsR/8A++nM4SNDYNGS xuy/ravD05idfpIiBIPNPzB9SQNlfGVeT81I5lFmol4RDCtVkWI9h3SG+picGRZ1 A9daHqXBDLmXJY5WLYwWpenU5NfoUPVKyshDRd/7VFS7VbtwAcJhcmjvUPi+jhSj GBkA6NldgHbF9MNBl99JAl0ZFA3enpvubaU2GdNItcpZz0zjhUECQKLiyqckJUU7 28P0Y/g2vKYlmnA/LXBAXsgVnPZzpz1+ejZa/S7XMAEQRV+5vZOQBpXPGjp85Nb5 cCZAqglFZkDiRyIw9kbWtAlTJp2h4coguXRqmsHkIwkcnEmQrCHqbDTi6J3i0b3B 8/hL7m5FfxVCgG2PxvRkIZ0E2GEpetTr2SJ/68lyGqHlufJPwoOm7IPUo2efABYy gjhouZaT1VBIs0IHCSsbrytP6uoy5fCO/HLJSApGR0Ev0btSecDbDVQdpCeiANEV nhqomgFL1GXlB0/2plFdgFCBzwviZ9l799UH7Sjf3dcdptR8BE3vdqHNb6L5aDyA Cs1rttySrMgzcHTWzzHmyKyCVUSvmaEfnRWDubwoMTN8SpGxhn4Q3T/Y0vy2vRib k9SY+e+x1V3jazFlKt46yLWJWcrIOcFqU+6az+mjYg8qqRRlrmve+5ny/spqyVhp HS13Q6R0VVIbf/9MJXLd1hWsh5PhLvix9QU+fEC6rz0DXOt+c2VyR61o/dmw7hhI K8tW548+MvygYriVPiOSwjn0gt0IdTlKLKeSR09RMxhwOifPxv/hEAFJL6+GkioQ IMX5d8Ir72rDWLroWiY/o0uVCdp4y/P9qfKDami2NUCqFRvbHbbp/cmcpWpz9zhE ErO5pvM/I/kJfHeoB4UWnc8djatc1FKHEtGuZqhSb2ZUSUBZkkpBvMl7i/SIWkA4 JNXYbsByUX7Bh7EM9yZCpSV/B5jjxkWH1eBR0wwI8iH+0pB6kudJMExUcmXvoGop hYwh9kXIP2JnNcXHU8cfZ32NKgZvuRuljMzdvneVuGWbWD/JnFJnirz4PwmptjQ9 pdCWYZXr/ZrHgOJNISf/pdafGYlvT9EUwO8OsB6oLq2AwPpgeDDMfs14FF2JwqZT slME8fHOFclLzweH2CFi9yJPD9TosOdXtlsx8niFUw1aRY5c0RwbKzjrqFhdOfvl ahEM01qp54HoqQyj5I9eq9gntTbvqLw1K/VuZkuNfSuB44J0jG+yexGx/Dh6FXdN zCJkfKMqhEji710RJOuVP/Mp+FuITFpFq+CilEhOmiOdQQEZLuBJXrSaWILt7UXr TZ7ZXpE7G+uTxAnH2rDvdEHrPpub2g+GaRRhEQFKCg/M35mfpLMTQN2YiSQCxP6c 5vkMobTHN3jsDzsOWYNeu+FqIYb2a6F6evfdpAAYYYuhVUn1nMridf7c2MGIDTSU K8V81kc9wjWhrkWWyCnUCoPggvGiXISpTXTG3tgCrlzvm2drWyGGt24UtSY5GyiL X3E= -----END ENCRYPTED PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIDVzCCAj+gAwIBAgIJAJBoG16aNi1MMA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNV BAYTAkdCMRUwEwYDVQQHDAxEZWZhdWx0IENpdHkxHDAaBgNVBAoME0RlZmF1bHQg Q29tcGFueSBMdGQwHhcNMTYwODIyMjAwMDExWhcNMjYwODIwMjAwMDExWjBCMQsw CQYDVQQGEwJHQjEVMBMGA1UEBwwMRGVmYXVsdCBDaXR5MRwwGgYDVQQKDBNEZWZh dWx0IENvbXBhbnkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA qSCQHmBVv2M3ZQtd7ofKSkgl3fcxr+lid6aKRyqfUkJDtSNxpfZR94oAi9i7ei3M MyIpsefWNqt7HK5PTSCgigmJHSnh/DHSfxOvok2FDZ56ZlnZ4XfwHv3vxRkD7H1O WHCuYPFhelhJjUjaAO47A+vm8g+lxKXphJhGdG4S6KSPC88c5xptJLzEUuO0FcrH oGpmmQOtvpAPsOyUqW1w2oF7zmEOvGv02xZ1DbdGZKk5icup0pM+DKrfchGzgiyx a3oCG7lE/vg7xoYC2arx526cM6bgPsAkZWLeAQoKj5zieNVKByo32DNUcDqqyfkB TGPBIesnLFahyexFQosgjQIDAQABo1AwTjAdBgNVHQ4EFgQUSOZq8hhBkRXFpvZc 10m9/gMEBBMwHwYDVR0jBBgwFoAUSOZq8hhBkRXFpvZc10m9/gMEBBMwDAYDVR0T BAUwAwEB/zANBgkqhkiG9w0BAQsFAAOCAQEAPma3df+ZzraSX11INZEX0XDSUHgo 5QvjO/Cutu4gI89qPCxhQ2FHo23OaPhAzC3eBrTzCPrntUHAJTLbRE9co4va8Jzt +M7enMy81CJJp/PEk6GdNhVL1JhBqihFZMiLstW5IpwOSESDPLLlUdOE8gyxWa81 R6hstrGiwNwNd+HYYGQMWWZ0Czs8a+sZqj5G2jdV32OP2BdOO5w2PRj10hlcSexY 7PovNzgh2l8WVxHopzDYXMGYF+WsUEzuMx3GPAslHm+0PhAGc2ccSga9egbqEev8 mpKkyZ0e/z4dbQfnZ1+AsXzdLtGZOtDBt3++tahQXv6WSlaY+v+SbOYYBA== -----END CERTIFICATE----- [dwoodhou@i7 ~]$ curl -k -v -E ./privkey.pem:asdf https://localhost:8443/data.txt * Trying 127.0.0.1... * Connected to localhost (127.0.0.1) port 8443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * unable to load client cert: -8018 (SEC_ERROR_UNKNOWN_PKCS11_ERROR) * NSS error -8018 (SEC_ERROR_UNKNOWN_PKCS11_ERROR) * Unknown PKCS #11 error. * Closing connection 0 curl: (58) unable to load client cert: -8018 (SEC_ERROR_UNKNOWN_PKCS11_ERROR) If I build curl against OpenSSL or GnuTLS instead of NSS, this appears to work. I don't think it's curl's fault; I think we just don't parse PKCS#8 files with -----BEGIN ENCRYPTED PRIVATE KEY----- at all. Despite bug 630100 which made it look like this *had* been fixed...
Sorry, bug 631000 ... or maybe bug 614531? Either way, not actually fixed... :)
nss-pem currently accepts headers like this: -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,89CFC0A0B653CBDF ... where the decryption parameters are taken directly from the text whereas for PKCS #8 we need to use an ASN1 decoder to get them. Do I understand the problem correctly?
Yep. Your torture tests should include keys generated/mangled in a variety of ways... # PKCS#8 encrypted (PKCS#5 v2.0), HMAC-SHA1 openssl pkcs8 -topk8 -in key.pem -out key-pkcs8-crypt.pem -v2 aes258 -v2prf hmacWithSHA1 -----BEGIN ENCRYPTED PRIVATE KEY----- # PKCS#8 encrypted (PKCS#5 v2.0), HMAC-SHA256 openssl pkcs8 -topk8 -in key.pem -out key-pkcs8-crypt.pem -v2 aes258 -v2prf hmacWithSHA256 -----BEGIN ENCRYPTED PRIVATE KEY----- # PKCS#8 unencrypted openssl pkcs8 -topk8 -in key.pem -nocrypt -----BEGIN PRIVATE KEY----- # PKCS#1 unencrypted openssl rsa -in key-pkcs8-crypt.pem -out key-pkcs1.pem -----BEGIN RSA PRIVATE KEY---- # PKCS#1 (legacy OpenSSL encrypted) openssl rsa -in key-pkcs8-crypt.pem -out key-pkcs1-crypted.pem -aes128 -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,03C0E0115419AD1EFE79C6B0D304A5EB openssl rsa -in ke2.pem -out ke3.pem # PKCS#12 openssl pkcs12 -export -out foo.p12 -inkey foo -in cert -certfile ca.cert -chain We really should expand https://fedoraproject.org/wiki/PackagingDrafts/SSLCertificateHandling to suggest that apps should automatically handle all of these, not *just* RFC7512 IDs.
And those just for RSA, of course. We should cover other types of keys too, ideally.
*** Bug 873858 has been marked as a duplicate of this bug. ***
I have spent some time debugging NSS internals and found some ASN1 templates that helped me to extract decryption parameters out of PKCS #8 key files. The output looks like this: Encryption Algorithm: PKCS #12 V2 PBE With SHA-1 And 3KEY Triple DES-CBC Parameters: Salt: 2f:46:98:4e:f2:90:ee:17 Iteration Count: 2048 (0x800) ... or this: Encryption Algorithm: PKCS #5 Password Based Encryption v2 Encryption: KDF: PKCS #5 Password Based Key Dervive Function v2 Parameters: Salt: 30:57:b8:36:8a:0c:16:e1 Iteration Count: 1 (0x1) Cipher: DES-EDE3-CBC Args: 04:08:8a:a4:bb:6e:43:2e:95:53 ... or this: Encryption Algorithm: PKCS #5 Password Based Encryption v2 Encryption: KDF: PKCS #5 Password Based Key Dervive Function v2 Parameters: Salt: 58:2b:65:6e:20:96:68:01 Iteration Count: 2048 (0x800) Cipher: AES-128-CBC Args: 04:10:0f:af:03:9e:87:85:8e:ab:1d:ea:67:78:e8:a4: 6c:7b I am not sure if there is a generic enough way to decrypt them using NSS API, though, and do not feel like (re)implementing all the code myself. Anyway, I am attaching my experimental patches for both nss and nss-pem in case someone wants to experiment further with that.
Created attachment 1194072 [details] [PATCH] secutil: extract decryption parameters out of PKCS #8 key files
Created attachment 1194073 [details] [PATCH] nss-pem: extract decryption parameters out of PKCS #8 key files
NSS can already do all this, can't it? Because it already has support for PKCS#12 objects, and those can *contain* PKCS#8 objects. Perhaps the way forward is to expand the existing NSS support for PKCS#12, to also handle PKCS#8 directly? Or maybe in nss-pem you could construct a PKCS#12 'wrapper' to contain the PKCS#8 object you're trying to decode, but that's a little horrid.
Not exactly, NSS has problems handling PKCS#12 files with new options: bug 1220573
Hm, thanks. I'll add those to my tests at http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am We should add non-RSA key types and add passing that test suite to the Fedora packaging guidelines for packages which can use SSL certs. But still we only want to add the missing bits *once* to NSS not in multiple places. I am confused by the difference between PEM and PKCS#12 handling... for PEM we have nss-pem but NSS has native support for importing PKCS#12 files -- and can presumably import them with CKA_TOKEN=CK_FALSE so that they are purely session objects, not actually *stored*. Why the difference?
well, I'm talking about using PKCS#12 files to store private keys, that means encrypted private keys, so to use them you need to be able to decrypt them and to decrypt you need to understand the encryption format for PKCS#12 files there are to encryption formats (they differ in how the password is transformed to encryption and MAC key), NSS doesn't support the new format and yes, fixing NSS is preferable
There are *plenty* of variants which we need to support. You haven't even touched on the OpenSSL bugs with the key derivation, and the fact that non-ASCII passphrases may need to be treated differently to account for that. Here's an attempt at collecting the cases that need to be supported. My plan is to expand the existing Fedora packaging guidelines (for which NSS patches already exist, to load the right PKCS#11 tokens and accept RFC7512 PKCS#11 URIs), to cover these rules too. Feedback would be very much welcomed: http://david.woodhou.se/draft-woodhouse-cert-best-practice.html
In comment #11 I've already mentioned my torture test suite which exercises a lot of the problematic use cases. We should try those with curl when built against NSS, and see what fails.
oh, yes, there are multitude of formats and encryption ciphers, not to mention non-standard but common or common buggy implementations that should be supported, but we need to start somewhere. And that somewhere is, I think now, for a bit of a off-topic: In the best practice document, I haven't noticed you writing about any configuration options of the PKCS#12 or PKCS#8 files except the bulk cipher and key derivation method, IOW, there's no mention of the HMAC used, salt size, iteration count or hash used for key derivation. For PBES2 all of that is variable (and some of it may actually be variable for PBES1 too, though my memory is fuzzy about that). other, minor item, is that not only DSA above 1024 bit is undefined for TLS, it is in practice undefined completely for TLS 1.2 (yes, implementations do interoperate in specific configurations, but it's more of a good will on their part than result of some standard). In general, I really like your approach and goal, feel free to contact me if you want to discuss it further (I'm also on Freenode on #fedora-security and #fedora-admin) or hit some roadblocks (I'm the head crypto QA on the RHEL side, so I may be able to poke the developers and maintainers in harder to avoid way :) ).
*** Bug 1410569 has been marked as a duplicate of this bug. ***
Since the PKCS#12 uses the same identifiers and the same options, the file options from this https://github.com/redhat-qe-security/keyfile-corpus are mostly applicable, even if basically all files there are PKCS#12 files.
python-exabgp-4.0.0-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9aca13bcc7
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still not implemented.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle. Changing version to '30.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I am afraid this is WONTFIX. I do not have time to work on this myself and nss-pem does not have any other contributors these days. Feel free to reopen with link to an upstream pull request that implements it.