Nixpkgs: Provide more assistance for users to find SSL certificates (the "unable to get local issuer certificate" problem)

Created on 26 Jul 2014  Â·  37Comments  Â·  Source: NixOS/nixpkgs

This caused me a big headache yesterday. A solution (for git) is to install cacert and then run GIT_SSL_CAINFO=$HOME/.nix-profile/etc/ca-bundle.crt, but when running outside nixos that environment variable isn't set and there's no warning/indication that you'd need to set anything.

Basically this means curl/git are broken out of the box.

A nice thing would be to print "Curl has installed but no SSL certificates are currently available, which means all SSL operations will fail. To add SSL certificates, install the cacert package, then set CURL_CA_BUNDLE=$HOME/.nix-profile/etc/ca-bundle.crt in your environment", in bright red, when curl is installed, and a similar message for git.

It would also be nice if the packages just shipped with a certificate list.

enhancement

Most helpful comment

Just hit this while playing with Nix. Is the fix still planned? Looks like it is not included in the 16.03 milestone any more.

All 37 comments

Is it viable to make cacert a dependency of curl? @edolstra

Why not just make cacert package default for curl and git? User can still
override this, i don't see a problem with this.
On Jul 26, 2014 9:48 PM, "lethalman" [email protected] wrote:

Is it viable to make cacert a dependency of curl?

—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/3382#issuecomment-50246539.

Even with the cacert package, you still need to point curl + git to the right place, I believe.

Maybe if a .curlrc file was provided pointing to the cacert's location.

For the failure case see for example https://gist.github.com/kevinburke/4d85873466903ba2e4c0

Yes, because CURL_CA_BUNDLE is not set, but if you set this in curl
wrapper, it should be just fine.
On Jul 26, 2014 9:56 PM, "Kevin Burke" [email protected] wrote:

For the failure case see for example
https://gist.github.com/kevinburke/4d85873466903ba2e4c0

—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/3382#issuecomment-50246765.

@offlinehacker that's what I said, make curl depend on cacert. Did you want to say something else?

Same thing
On Jul 26, 2014 10:11 PM, "lethalman" [email protected] wrote:

@offlinehacker https://github.com/offlinehacker what's what I said,
make curl depend on cacert. Did you want to say something else?

—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/3382#issuecomment-50247126.

+1

By far the easiest solution is to make OpenSSL (not curl) depend on cacert. However, that means that every change to cacert triggers a big rebuild.

Well in that case it might be better to resolve per package.

On Mon, Jul 28, 2014 at 6:25 PM, Eelco Dolstra [email protected]
wrote:

By far the easiest solution is to make OpenSSL (not curl) depend on
cacert. However, that means that every change to cacert triggers a big
rebuild.

—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/3382#issuecomment-50361683.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.11 (GNU/Linux)

mQENBFEY1PEBCADPOfERF2wo4qeoq9L1m2z4pKfWqNd4B6BsoFUWPNd7BXmY+9JG
jJddSkmYobWec7XjAFTBL0Xbttt+rK9SIED2dCOmU1FYMQElhGlM3PNA3kaiQFeV
ijgH318GCfZzDd0dWa5TN/IshVeWXwgngsIEmZTVf1VSeb3eO3B8Fxe3zsSLUq0b
71MmU5eLVP9pMkm5V5BTYp+lV70FIekKygkKq+uTDo1csWUatbs4Qvgv37Bymy2t
oTwOBXGoinQk5N/6asR1jWs3vKv0L0SruoZy/kEG/jXb4l2OZUP85EVMganYKouE
OchVmcmhBdWV+t3HK4r2ATfyEcMRzvzSflA1ABEBAAG0Jkpha2EgSHVkb2tsaW4g
PGpha2FodWRva2xpbkBnbWFpbC5jb20+iQE+BBMBAgAoBQJRGNTxAhsDBQkB4TOA
BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRD6Zxi5hZclKnXNCACLOKa8abQp
eTWv9SXUwC7LVM5pP2mXcgn+Ipqr6YWBdLx4Iij0YlvUok9VeKvwTpUlT+cx++o3
wCM3AYrUyJE+zrtw49lInUmutz9seqJLU895oq+D+UuGoORrLBpEZrYR5f83uUmQ
E3Z1ZmWrNGXYtITWDtVZD/KauMF2nkPcmy/XaYXhd4WHD81DGNlKtGAHig6A3Phc
8Mr0A4yLDeRQJm8lCFEsxMJUNTupgY+ybbsMfVGx1gQvvGOTioV8CLCoRchUCCcm
YPArFg40KzIDSNjwdo9EVZDnlPx1hbOppfQydxP+JVnZsqoYmVY4UhIWi/NfOl3V
UMjl338INW1zuQENBFEY1PEBCADRSIfelOMjaTH7IfpMFFUc5Gys//njFnW9QAUg
wyfs2AFxUp6vKQ7nxXQiJXVhKTwe9iqo+oGxaHp4AeTjC7vXsfMuF5g5lfttbAo3
YEobEe6OG5so41nbwan6SyeIIQ2AmQqJBw8TKKMSec2qUN0Pw7iZRs0o9uJM/obG
DPsAsMOQgNLxJyMCP7X2jBtDXxkMFVHMmk50Tl3h3Fi9qWuNxgTXjs0tUvKkXiu2
Pco952jnm7HpCIKBek2pqR/UJXXb5qxy5G6Lc0qaMWZ5GKnSMTJmTY6Xl44EnaLK
zh0rqgF9qpoWck470ZbiGASMtB008hy2l0cyxUfvDaS3tY4hABEBAAGJASUEGAEC
AA8FAlEY1PECGwwFCQHhM4AACgkQ+mcYuYWXJSoT6AgAkvzvC0EGmeCR3cn9O3Gf
yG00Kqk9/1gJvlphis7AAce8iUgU+4xd94Vp0u8rghpdy88xKN5lF1W2YZQmmBaf
AVe6b7TOg6kxc3GKkVsWDxNyQKkpB46BwefIGaSljH7502X9aEWosrqWyJJNYCtt
QDit4BysX0Ww3Ka5Rx6ZFhC9ybPKoW2i8JwpyBaXDt7R2k+PC/ClBf9qzL+sb2es
zh/zCMVKNdm8KUITHU/5lgn2qZpUFZwiASPCMGGFP9u8g6UKeUTYTPD+GWaHIW63
RAgNIAffxx0M1r3P/2ipkAdI3NX/1iBKDQNG8Odsf+BswFKrNCnyUDdLPvJAhODS
gw==
=tmrm
-----END PGP PUBLIC KEY BLOCK-----

On second thought, there is a big security argument against making _anything_ depend statically on cacert: it makes it impossible to remove a CA centrally. So in a DigiNotar situation, you have to check that no package in the store still has the revoked CA.

Maybe the Nix installer should just run nix-env -i cacert (with Nix's profile.sh setting SSL_CERT_FILE appropriately).

But if SSL_CERT_FILE is preset, it can be still overriden, and provides
better user experience, if user does not set SSL_CERT_FILE or similar env
variable.

On Mon, Jul 28, 2014 at 7:16 PM, Eelco Dolstra [email protected]
wrote:

Maybe the Nix installer should just run nix-env -i cacert (with Nix's
profile.sh setting SSL_CERT_FILE appropriately).

—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/3382#issuecomment-50368347.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.11 (GNU/Linux)

mQENBFEY1PEBCADPOfERF2wo4qeoq9L1m2z4pKfWqNd4B6BsoFUWPNd7BXmY+9JG
jJddSkmYobWec7XjAFTBL0Xbttt+rK9SIED2dCOmU1FYMQElhGlM3PNA3kaiQFeV
ijgH318GCfZzDd0dWa5TN/IshVeWXwgngsIEmZTVf1VSeb3eO3B8Fxe3zsSLUq0b
71MmU5eLVP9pMkm5V5BTYp+lV70FIekKygkKq+uTDo1csWUatbs4Qvgv37Bymy2t
oTwOBXGoinQk5N/6asR1jWs3vKv0L0SruoZy/kEG/jXb4l2OZUP85EVMganYKouE
OchVmcmhBdWV+t3HK4r2ATfyEcMRzvzSflA1ABEBAAG0Jkpha2EgSHVkb2tsaW4g
PGpha2FodWRva2xpbkBnbWFpbC5jb20+iQE+BBMBAgAoBQJRGNTxAhsDBQkB4TOA
BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRD6Zxi5hZclKnXNCACLOKa8abQp
eTWv9SXUwC7LVM5pP2mXcgn+Ipqr6YWBdLx4Iij0YlvUok9VeKvwTpUlT+cx++o3
wCM3AYrUyJE+zrtw49lInUmutz9seqJLU895oq+D+UuGoORrLBpEZrYR5f83uUmQ
E3Z1ZmWrNGXYtITWDtVZD/KauMF2nkPcmy/XaYXhd4WHD81DGNlKtGAHig6A3Phc
8Mr0A4yLDeRQJm8lCFEsxMJUNTupgY+ybbsMfVGx1gQvvGOTioV8CLCoRchUCCcm
YPArFg40KzIDSNjwdo9EVZDnlPx1hbOppfQydxP+JVnZsqoYmVY4UhIWi/NfOl3V
UMjl338INW1zuQENBFEY1PEBCADRSIfelOMjaTH7IfpMFFUc5Gys//njFnW9QAUg
wyfs2AFxUp6vKQ7nxXQiJXVhKTwe9iqo+oGxaHp4AeTjC7vXsfMuF5g5lfttbAo3
YEobEe6OG5so41nbwan6SyeIIQ2AmQqJBw8TKKMSec2qUN0Pw7iZRs0o9uJM/obG
DPsAsMOQgNLxJyMCP7X2jBtDXxkMFVHMmk50Tl3h3Fi9qWuNxgTXjs0tUvKkXiu2
Pco952jnm7HpCIKBek2pqR/UJXXb5qxy5G6Lc0qaMWZ5GKnSMTJmTY6Xl44EnaLK
zh0rqgF9qpoWck470ZbiGASMtB008hy2l0cyxUfvDaS3tY4hABEBAAGJASUEGAEC
AA8FAlEY1PECGwwFCQHhM4AACgkQ+mcYuYWXJSoT6AgAkvzvC0EGmeCR3cn9O3Gf
yG00Kqk9/1gJvlphis7AAce8iUgU+4xd94Vp0u8rghpdy88xKN5lF1W2YZQmmBaf
AVe6b7TOg6kxc3GKkVsWDxNyQKkpB46BwefIGaSljH7502X9aEWosrqWyJJNYCtt
QDit4BysX0Ww3Ka5Rx6ZFhC9ybPKoW2i8JwpyBaXDt7R2k+PC/ClBf9qzL+sb2es
zh/zCMVKNdm8KUITHU/5lgn2qZpUFZwiASPCMGGFP9u8g6UKeUTYTPD+GWaHIW63
RAgNIAffxx0M1r3P/2ipkAdI3NX/1iBKDQNG8Odsf+BswFKrNCnyUDdLPvJAhODS
gw==
=tmrm
-----END PGP PUBLIC KEY BLOCK-----

EDIT: More general proposal based on @edolstra one. nix-env activation scripts as
nix-support/nix-env. These nix-support/nix-env scripts will be concatenated in a profile.sh derivation. This profile.sh will be symlinked in the profile (same level of manifest.nix). Then profile.d/nix.sh will simply source ~/.nix-profile/profile.sh .
It could even be used for environment.systemPackages.

At that point, curl would just have propagatedUserEnvPkgs = [ cacert ]; . That might solve also other problems like browser plugins that can be installed without creating a wrapper derivation for each change, or gdkpixbuf/immodules cache, or icons cache, or xmonad with contributions, or...

That's not the functional way, however. But for non-ABI/API stuff, like cacert or other stuff might work. We shall not abuse it.

Right now for example nix's curl and wget don't read the Darwin keychain and I'm forced to provide my own SSL_CERT_FILE (aka install nss-cacert) if I want to access any https website. If I do, I don't benefit from the system-wide certs that I installed to access my company's internal services.

I believe a better solution would be to define a system-wide CA store for NixOS and configure OpenSSL to use the host's CA store by default (also on other systems). In NixOS's configuration.nix you would also have a ssl_ca list option to manage the list of certs available in the store. Eg: ssl_ca = pkgs.cacert.certs - ["china"]).

I believe a better solution would be to define a system-wide CA store

We do have that already, at least on NixOS. BTW, I had created an issue for related stuff #8247.

I've been using nixos for ~6 months and just today encountered this problem with git for the first time. Any idea what changed?

@chris-martin me too. Installing cacert didn't seem to help. I don't think it was caused by upgrading anything.

Added to the 16.03 milestone because we're going to get endless reports if this isn't fixed

Yup, same here. ~6 months, then a stack build failed getting a github https URL due to this.

I'm finding that anything I run in nix-shell doesn't have certs, but the same packages installed either as systemPackages or with nix-env work.

My hacky fix was to put export GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt in my .bashrc.

My fix for git clone over https on OS X was to do the following:

git config --global http.sslcainfo ~/.nix-profile/etc/ca-bundle.crt

It is slightly annoying as it worked fine in February when cloning from https repos without the config change to git.

@chris-martin: the nix-shell problem is something different, I believe. See https://github.com/NixOS/nixpkgs/pull/13445#issuecomment-199190972.

Any update?

When I try to just clone something via https:

fatal: unable to access 'https://github.com/robbyrussell/oh-my-zsh.git/': SSL certificate problem: unable to get local issuer certificate

But via ssh it work.

@lally confirm, your hacky fix GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt work for me, thanks!

can this be fixed properly?

Just hit this while playing with Nix. Is the fix still planned? Looks like it is not included in the 16.03 milestone any more.

I'm not sure if this is related, but I have the case of an internally hosted Git server where I get this same error when using git/curl, but openssl s_client -connect domain.com:443 is successful; specifying ~/.nix-profile/etc/ssl/certs/ca-bundle.crt doesn't make a difference.

(The openssl call reveals that the certificate is signed by Go Daddy, which is indeed present in ca-bundle.crt. Using the macOS curl works.)

For those wondering why fetchgit normally works but their own custom fetcher isn't working, probably this: https://github.com/NixOS/nixpkgs/blob/7261ffc18e28eeecc318db5f4e34e9a3b8cef438/pkgs/build-support/fetchgit/default.nix#L64

In fact, cacert has a setup hook https://github.com/NixOS/nixpkgs/blob/master/pkgs/data/misc/cacert/setup-hook.sh

Edit: ah, but the variables are named different.

Ran into this problem today in a nix-shell FHS environment where my build git clones over https. The solution was similar to this comment; added cacert to targetPkgs and defined GIT_SSL_CAINFO in the fhs.nix:

# ...
{
  name = "fhs";
  targetPkgs = pkgs: with pkgs; [
    # ...
    cacert
    # ...
  ];

  # ...
  profile = ''
    PS1="\n$PS1\n\$ "
    export GIT_SSL_CAINFO=~/.nix-profile/etc/ssl/certs/ca-bundle.crt
  '';
  # ...
}

Ran into this on OSX (10.14.6) as well, the fix was an adjustment of @mitchty's https://github.com/NixOS/nixpkgs/issues/3382#issuecomment-198990799

git config --global http.sslcainfo ~/.nix-profile/etc/ssl/certs/ca-bundle.crt

Nice to stumble upon it 6 years after the initial discovery. Still lurking and still causing trouble. For me it was a per project nix-shell and direnv

Things have improved since, what's really had about this issue is that it needs to be reproducible. Or at the very least, list exact steps and details that led to it.

I don't know if it is related, but...

I have a shell.nix like this

with import <nixpkgs> {};
stdenv.mkDerivation rec {
  name = "env";

  buildInputs = [
    rustup
    pkgconfig openssl cacert curl
    SDL2 SDL2_ttf
  ];
}

and I'm trying to build a cargo project with SDL2 and the "bundled" feature. That is, cargo.toml looks like

[dependencies]
sdl2 = {version = "0.34", features=["ttf", "bundled"]}

when I try to build, I got

   Compiling sdl2-sys v0.34.2
error: failed to run custom build command for `sdl2-sys v0.34.2`

Caused by:
  process didn't exit successfully: `/.../target/debug/build/sdl2-sys-601f99ba1cf727da/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Command 'curl' failed:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
', /.../.cargo/registry/src/github.com-1ecc6299db9ec823/sdl2-sys-0.34.2/build.rs:53:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Is it related in some ways? Is there a way to get around this issue? (Using NixOs but quite noob in this regard)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

grahamc picture grahamc  Â·  3Comments

ayyess picture ayyess  Â·  3Comments

edolstra picture edolstra  Â·  3Comments

langston-barrett picture langston-barrett  Â·  3Comments

tomberek picture tomberek  Â·  3Comments