3

Given: an absolutely isolated LAN with a number of web-services using a local CA server.

All user hosts have ca-certificates installed and .crt files were installed by update-ca-certificates. Browser-like software, e.g. Chrome and like, are working without reporting.

But every command-line utility, e.g. curl, git, wget, etc. encounter errors because they can't verify local issuer.

Message from curl:

curl: (60) SSL certificate problem: unable to get local issuer certificate.

Most recipes involve just intallation of packages for Internet-wide certs. A few mention use of /etc/pki/whitelist path and update-ca-trust script, but both are missing in system or reposutories.

Host OS: Debian 11

Improve this question
3
  • "and .crt files were installed by update-ca-certificates": how did you precisely do that? Can you give more details?
    – A.B
    Jun 2 at 11:45
  • @telcom that's what I did
    – Swift
    Jun 2 at 13:50
  • @A.B Just after writing that comment I realized that the OP probably did not know that a directory needs to be created under /usr/local/share/ca-certificates, as that little pitfall is not exactly obvious and caused me a quite a bit of head-scratching when I first tried to add a local CA certificate "the Debian way". So I wrote my answer, let's see if it helps. I'll be deleting my earlier comments as redundant.
    – telcoM
    Jun 2 at 14:19

1 Answer 1

Reset to default
11

Create a directory under /usr/local/share/ca-certificates with the name of your choosing, and place the public CA certificate of your CA server into it in PEM format, as a *.crt file. Then run update-ca-certificates.

It will add your local CA certificate in the system-wide /etc/ssl/certs in several formats:

  • as a OpenSSL-style directory of PEM-formatted certificates with symlinks with certificate hashes at /etc/ssl/certs
  • as a single file of all trusted CA certs in PEM format at /etc/ssl/certs/ca-certificates.crt
  • and in any other forms that may be created by any script(s) placed in /etc/ca-certificates/update.d, e.g.:
    • if a Java package has been installed, there will be a /etc/ca-certificates/update.d/jks-keystore script that will generate a JKS keystore of CA certificates as /etc/ssl/certs/java/cacerts.

There is a man page man update-ca-certificates, and more documentation in /usr/share/doc/ca-certificates. However, unless you read all the documentation thoroughly, you might miss the fact that you'll need to create a directory under /usr/local/share/ca-certificates and place your CA certificate within it; any certificate files at the top /usr/local/share/ca-certificates level will be ignored.

The update-ca-certificates command is used in Debian and related distributions; the update-ca-trust you found mentioned originates from Fedora, and seems to be also used in Arch (and related distributions perhaps?).

Both commands do basically the same job, although the exact pathnames vary somewhat between them, as each family of distributions has maintained a slightly different directory hierarchy of system-wide CA certificates.

Improve this answer
4
  • Hmm, at which stage they get ignored? update-ca-certuficates certainly does't ignore them, whem messaging "X certificates were added" and they appear in list. But I was told by LDAP admins not to do sub-dirs and root certificate is in /usr/local/share/ca-certificates
    – Swift
    Jun 2 at 19:10
  • Oh, it seemed to be required in an older version of Debian. Maybe it was a bug that has been fixed since then.
    – telcoM
    Jun 2 at 20:27
  • 1
    The "distributed" location at /usr/share probably needs subdirs, the "site" location at /usr/local/share didn't as far as I can remember.
    – u1686_grawity
    Jun 3 at 8:21
  • @u1686_grawity /usr/share would also require editing config file. Oddly enough, adding subir kind of worked (still warnings, but no failures now)
    – Swift
    Jun 6 at 19:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .