Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to use PKCS12 certificate for TLS under macOSX #5403

Closed
ElMostafaIdrassi opened this issue May 16, 2020 · 2 comments
Closed

Unable to use PKCS12 certificate for TLS under macOSX #5403

ElMostafaIdrassi opened this issue May 16, 2020 · 2 comments

Comments

@ElMostafaIdrassi
Copy link

ElMostafaIdrassi commented May 16, 2020

Reopening another issue since the old one didn't get any attention and the bug is still occurring on multiple machines.

I did this

I tried authenticating to a server using a PKCS#12 certificate.
I used the following command :

ABSOLUTE/PATH/TO/curl --cert ABSOLUTE/PATH/TO/cert.p12 --pass PASSWORD --verbose https://github.com

I passed the absolute path of the PKCS#12 certificate and not a relative path.

As a result, I got the following output :

*   Trying 140.82.118.3:443...
* Connected to github.com (140.82.118.3) port 443 (#0)
* ALPN, offering http/1.1
* WARNING: SSL: Certificate type not set, assuming PKCS#12 format.
* SSL: Can't find the certificate "/Users/user/Desktop/MyCert.p12" and its private key in the Keychain.
* Closing connection 0
curl: (58) SSL: Can't find the certificate "/Users/user/Desktop/MyCert.p12" and its private key in the Keychain.

I expected the following

Normally, the output is as follows :

*   Trying 140.82.118.4:443...
* TCP_NODELAY set
* Connected to github.com (140.82.118.4) port 443 (#0)
* ALPN, offering http/1.1
* WARNING: SSL: Certificate type not set, assuming PKCS#12 format.
* Client certificate: Alice
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: github.com
* Server certificate: DigiCert SHA2 Extended Validation Server CA
* Server certificate: DigiCert High Assurance EV Root CA
> GET / HTTP/1.1
> Host: github.com
> User-Agent: curl/7.68.0-DEV
> Accept: */*
> 

curl/libcurl version

Curl master branch built as follows :

autoreconf --install
./configure --prefix="/Library/MyOrg" --with-darwinssl CFLAGS="-mmacosx-version-min=10.9"

[curl -V output]

/Library/MyOrg/bin/curl --version
curl 7.71.0-DEV (x86_64-apple-darwin19.0.0) libcurl/7.71.0-DEV SecureTransport zlib/1.2.11
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IPv6 Largefile libz NTLM NTLM_WB SSL UnixSockets

Operating system

macOSX 10.12, macOSX 10.13, macOSX 10.14, macOSX, 10.15

To reproduce the bug

PKCS12 Certificate
CURL Binaries

The PKCS12 Certificate was created using OpenSSL as follows :

openssl genrsa -out MyKey.pem
openssl req -new -key MyKey.pem -out MyCertCSR.csr
openssl x509 -req -in MyCertCSR.csr -signkey MyKey.pem -out MyCert.crt
openssl pkcs12 -export -out MyCert.p12 -inkey MyKey.pem -in MyCert.crt

Make sure the P12 was not imported before testing. Check the keychain and delete BOTH the cert and its corresponding key as follows
If you only delete the cert AND leave the key lingering behind, the test will not fail because the key is in the keychain

image
image

To fix the bug

The reason this is happening is as follows :

In the method CopyIdentityFromPKCS12File, SecItemImport is used with importKeychain set to NULL. Therefore the PKCS12 is not imported into the keychain.

Later on, in order to get a SecIdentityRef from the SecCertificateRef, the function
SecIdentityCreateWithCertificate is called (remark that the if(itemID == CFDictionaryGetTypeID()) condition is false, leading to the else if(itemID == SecCertificateGetTypeID()) condition which is true).

However, because the PKCS#12 private key was not imported to the keychain, the function fails with errSecItemNotFound.

The pull request #4800 gives additional source code for testing and fixes this, but was rather dimissed and closed.

@bagder
Copy link
Member

bagder commented May 16, 2020

Closing an issue (#4801) just to file an identical one with a new number won't help at all. It will only annoy some of us.

Issues that aren't fixed stay that way for reasons (lack of time, energy, knowledge or skills for example) and you don't change those reasons by filing the same bug yet again.

@bagder bagder added the TLS label May 16, 2020
@ElMostafaIdrassi
Copy link
Author

ElMostafaIdrassi commented May 17, 2020

Well I am truly sorry you took it that way, but I reopened the issue because I was told the issue could not be reproduced about 3/4 months ago, and I responded by providing my own binaries, a source code that proves the origins of the bug, the fix, a P12 for testing purposes and the correct way to trigger the bug. I know you have other priorities, I just wanted to get this bug some more attention. Apologies again for any inconvenience as it was not my intent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants