0

This is a strange one: trying to connect to a server that requires local pem files, but I get this error:
cURL error 58: unable to load client key: -8178 (SEC_ERROR_BAD_KEY)

Strange thing is, that if I navigate to the path where the pem files are, it works. If I give the exact path, it gives the error.

Here are the commands that work:
cd /path/to
curl --insecure --key key.pem --cacert ca.pem --cert client.pem:xxxxxxxxx https://server.com/action/id
(replies with proper HTML)

These ones give the error:
cd /path/to
curl --insecure --key /path/to/key.pem --cacert /path/to/ca.pem --cert /path/to/client.pem:xxxxxxxxx https://server.com/action/file

Any ideas on how to run the command while also giving the exact paths? I'm completely bamboozled...

EDIT: Just realized it could be helpful:

curl --version:
curl 7.51.0 (x86_64-redhat-linux-gnu) libcurl/7.51.0 NSS/3.28.4 zlib/1.2.8 libidn2/0.16 libpsl/0.6.2 (+libicu/50.1.2) libssh2/1.4.2 nghttp2/1.21.1 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz HTTP2 UnixSockets PSL

uname -a:
4.9.20-11.31.amzn1.x86_64 #1 SMP Thu Apr 13 01:53:57 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Pekko Tuomisto
  • 11
  • 1
  • 3
  • Are you sure there are no (unescaped) spaces in paths? Have you tried quoting the paths? – randomir Oct 17 '17 at 14:45
  • 1
    From `man curl`: "--cert [..] If curl is built against the **NSS SSL** library then this option can tell curl the nickname of the certificate to use within the NSS database defined by the environment variable SSL_DIR (or by default /etc/pki/nssdb)." and "**If you want to use a file from the current directory, please precede it with `./` prefix**, in order to avoid confusion with a nickname." – randomir Oct 17 '17 at 14:48
  • Yes, paths are `/word/word/word/file.pem`. And also tried `"/word/word/word/file.pem"`, same result. Using the file from the current directory works fine, it's the path that is failing. Yet using (directly copy-pasted) `cat /word/word/word/file.pem` works. – Pekko Tuomisto Oct 17 '17 at 14:50
  • Can you try running the first version with `SSL_DIR` unset, like: `SSL_DIR= curl ...`? Or run it with paths prefixed with `./`, like `curl ... --cert ./client.pem:xxxx`? – randomir Oct 17 '17 at 14:51
  • Narrowed it down a bit: It's --cert that gets offended by the path. `SSL_DIR= curl ...` didn't help Could it be the password for the client.pem file? ------------ Continued testing: adding any path between `--cert` & `client.pem:xxxxx` causes the error. Maybe curl doesn't understand the path anymore, due to the `:xxxxxx` part? – Pekko Tuomisto Oct 17 '17 at 14:56
  • Does it fail when you run it from the certs dir with `curl .. --cert ./client...`? If it does, that means curl never actually read the `client.pem` from your file, but from the NSS store. – randomir Oct 17 '17 at 15:01
  • 1
    There is a similar question here that's answered. https://stackoverflow.com/questions/22499425/ssl-certificate-generated-with-openssl-not-working-on-nss – madzhara Oct 17 '17 at 15:03
  • @randomir: yes it does. What is an NSS store? @madzhara: tried renaming the header, got `curl: (58) unable to load client cert: -8018 (SEC_ERROR_UNKNOWN_PKCS11_ERROR)` – Pekko Tuomisto Oct 17 '17 at 15:09
  • See my second comment, and check your `man curl` (section `--cert`). NSS database contains certs you reference by "nickname" with the `--cert` option. Odds are your `client.pem` and/or `key.pem` are in an invalid format. – randomir Oct 17 '17 at 15:27
  • Thanks for all the help! Made me search for the right things with the correct keywords :) – Pekko Tuomisto Oct 19 '17 at 05:49

1 Answers1

1

Here is the solution that worked:

1st convert the .p12 file to key & cert .pem files:
openssl pkcs12 -in given_keystore.p12 -out key.pem -nodes
openssl pkcs12 -in given_keystore.p12 -out cert.pem -nokeys

2nd test it works:
curl --cert ./cert.pem --key ./key.pem https://provider.com/service/foobar -v
→ result is correctly 404 not found (instead of errors or 403)

Pekko Tuomisto
  • 11
  • 1
  • 3