Bad cert when accessing the General registry

I just started getting errors about untrusted SSL cert when accessing the General registry.

If I try to update General:

(@v1.10) pkg> registry update General
    Updating registry at `~/.julia/registries/General.toml`
┌ Error: Some registries failed to update:
│     — /Users/dmatz/.julia/registries/General.toml — failed to download from Exception: RequestError: HTTP/2 301 (SSL certificate problem: Invalid certificate chain) while requesting
└ @ Pkg.Registry ~/.julia/juliaup/

Another type of error when my CI system tries to get General in a fresh depot:

$ julia -e 'using Pkg; Pkg.Registry.add("General")'
ERROR: could not download
  [1] pkgerror(msg::String)
    @ Pkg.Types /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Pkg/src/Types.jl:55
  [2] (::Pkg.Types.var"#82#85"{Pkg.Types.Context, String, Pkg.Types.RegistrySpec})(tmp::String)
    @ Pkg.Types /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Pkg/src/Types.jl:1035
  [3] mktempdir(fn::Pkg.Types.var"#82#85"{Pkg.Types.Context, String, Pkg.Types.RegistrySpec}, parent::String; prefix::String)
    @ Base.Filesystem ./file.jl:729
  [4] mktempdir (repeats 2 times)
    @ ./file.jl:727 [inlined]
  [5] clone_or_cp_registries(ctx::Pkg.Types.Context, regs::Vector{Pkg.Types.RegistrySpec}, depot::String)
    @ Pkg.Types /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Pkg/src/Types.jl:1027
  [6] clone_or_cp_registries
    @ /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Pkg/src/Types.jl:1020 [inlined]
  [7] #add#7
    @ /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Pkg/src/Registry.jl:33 [inlined]
  [8] add
    @ /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Pkg/src/Registry.jl:29 [inlined]
  [9] #add#5
    @ /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Pkg/src/Registry.jl:26 [inlined]
 [10] add
    @ /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Pkg/src/Registry.jl:26 [inlined]
 [11] add(regs::Vector{String}; kwargs::Base.Iterators.Pairs{Union{}, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
    @ Pkg.Registry /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Pkg/src/Registry.jl:25
 [12] add
    @ /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Pkg/src/Registry.jl:25 [inlined]
 [13] #add#1
    @ /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Pkg/src/Registry.jl:24 [inlined]
 [14] add(reg::String)
    @ Pkg.Registry /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Pkg/src/Registry.jl:24
 [15] top-level scope
    @ none:1
caused by: HTTP/2 301 (Cert verify failed: BADCERT_NOT_TRUSTED) while requesting

Is anyone else seeing this?

what Linux distribution (and version) are you on?

The top example is on my Mac, and the bottom example is a CI job running on our Linux system, which is CentOS 7.

Ha. At CERN we have this problem as well, where the stock COS7 with Julia (which is official binary but the our software environment would overload a bunch of things) would give you cert error, but only if you’re not using the official binary from juliaup.

As for your local macOS laptop, I’m not sure, I just tried it now and it works fine.

Some co-workers are also seeing the issue, but only when on our company network. Must be an issue on our side.

Is there a proxy/firewall? Those will sometimes MITM your connections. In such cases there’s usually some company-specific certificate authority cert that needs to be added to allow the transparent proxy to perform this MITM. It will read all your traffic in such a case, even over HTTPS connections.


5 posts were split to a new topic: Unexpected end of data when updating registries with LocalPackageServer

If I use my browser to navigate to your us-west URL, it tries to download the registry. If I navigate to us-east, it seems to forward to “”, and my browser complains about an invalid certificate.

If I force Julia to use the us-west server, things are working great:


(To be clear, my original issue was unrelated to HTTP.jl.)

The root certificate for (which redirects to) is ISRG Root X2 and the root certificate for (and too) is ISRG Root X1. Is it possible that the former isn’t trusted (yet) by your system?

See for some more details. In particular they list a couple of test pages where you can verify the theory above. For example, present a valid certificate signed by ISRG Root X1 and a valid cert signed by ISRG Root X2.


Thanks for that detail, I’ll pass that along. I’ve opened a ticket with my company’s IT department. They must have changed something this week!


Not necessarily a change on your end since the redirection to was deployed yesterday. Regardless, all certs are valid as far as I can tell.

1 Like

You can locally try to curl the two letsencrypt URLs that Fredrik posted and check if the one doesn’t work. In that case that would confirm the issue.

I tried both and in both my browser and with curl, and everything worked fine. But continues to give me issues.

Did you mean .org? Because I get redirected to

I meant .net, sorry. Updated.

1 Like

My issue bounced through the bureaucracy for a week or so, but it finally made it to the network team. The issue appears to be resolved. Unfortunately, they didn’t leave any notes about what they did, so I’m not sure if it was the root cert or something else.

Thank you all again for help on this!

1 Like