|
Bugzilla – Full Text Bug Listing |
| Summary: | update-ca-certificates does not give feedback and lacks documentation | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Distribution | Reporter: | Andrew Daugherity <adaugherity> |
| Component: | Basesystem | Assignee: | Ludwig Nussel <lnussel> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | forgotten_JoZGrGEMhM, lnussel, meissner, novell-ugeuder, whdu |
| Version: | Leap 42.3 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | openSUSE 42.3 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Ludwig, would you have a look please? Thanks! I have same problem. Custom CA certificates from /etc/pki/trust/anchors/ doesnt work on openSUSE 13.2 (works fine on 13.1) I remember in 13.1 (or was it already 12.2?) the location /etc/pki/trust/anchors was indeed undocumented. But in 13.2 as of today the location is clearly stated on the man page update-ca-certificates(1). The information in /usr/share/doc/packages/ca-certificates/README could of course be improved by stating that administrators should install certificates /etc/pki/trust/anchors if that is the correct location (currently it does not work as reported in https://bugzilla.opensuse.org/show_bug.cgi?id=918944 and https://bugzilla.opensuse.org/show_bug.cgi?id=936709) The "does not gave feedback part" is very valid. If a certificate has wrong format it will be *silently* ignored, which is painful for the admin, because he has no clue that something went wrong. According to old Linux tradition programs are silent when the operation succeeds, but in case of an error there should be an error message. See https://bugzilla.opensuse.org/show_bug.cgi?id=936709 for an example. If I read the scripts correctly, the problem happens inside the /usr/bin/trust binary, which has no documentation. yes, it's a p11-kit issue This version of openSUSE changed to end-of-life (EOL [1]) status. As such it is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of openSUSE, or consider the bug still valid, please feel free to reopen this bug against that version, or open a new ticket. Thank you for reporting this bug and we are sorry it could not be fixed during the lifetime of the release. [1] https://en.opensuse.org/Lifetime Not much (if anything) has changed as of Leap 42.3. At the very least the documentation (man pages and readme) need editing for clarity. Also, the p11-kit man pages are completely missing. For comparison, CentOS 7 ships pkcs11.conf(5) and p11-kit(8) in p11-kit, and trust(1) in p11-kit-trust. Once these are installed, it would be a good idea to add trust(1) to the "SEE ALSO" section of update-ca-certificates(8). This is automated batch bugzilla cleanup. The openSUSE 42.3 changed to end-of-life (EOL [1]) status. As such it is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of openSUSE (At this moment openSUSE Leap 15.1, 15.0 and Tumbleweed) please feel free to reopen this bug against that version (!you must update the "Version" component in the bug fields, do not just reopen please), or alternatively create a new ticket. Thank you for reporting this bug and we are sorry it could not be fixed during the lifetime of the release. [1] https://en.opensuse.org/Lifetime |
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/600.2.5 (KHTML, like Gecko) Version/7.1.2 Safari/537.85.11 Build Identifier: Even when run with the -v option for verbose, it only lists the scripts run, but not the certificates handled, or even the number of certificates added/removed. /usr/share/doc/packages/ca-certificates/README does not clearly explain that user CA certificates should be installed into /etc/pki/trust/anchors, or what the "openssl trusted format" used by /etc/pki/trust is. "By default p11-kit looks into /usr/share/pki/trust/ resp /etc/pki/trust/ but there could be other plugins that serve as source for certificates as well" is poor grammar and unclear. Only by combining that with "Packages are expected to install their CA certificates in /usr/share/pki/trust/anchors" and a lot of trial and error was I able to infer that I should install my certs in /etc/pki/trust/anchors. Additionally, the change in the handling of /etc/ssl/certs (its being a symlink now, and needing to run update-ca-certificates, etc.) is not mentioned in the openSUSE release notes. I only discovered this from the SLES 12 release notes. Reproducible: Always Steps to Reproduce: 1. Add or remove a CA certificate file to /etc/pki/trust/anchors as inferred from the documentation. 2. Run 'update-ca-certificates'. Actual Results: # update-ca-certificates [No output.] # update-ca-certificates -v running /usr/lib/ca-certificates/update.d/50java.run ... creating /var/lib/ca-certificates/java-cacerts ... running /usr/lib/ca-certificates/update.d/70openssl.run ... creating /var/lib/ca-certificates/openssl ... running /usr/lib/ca-certificates/update.d/80etc_ssl.run ... running /usr/lib/ca-certificates/update.d/99certbundle.run ... creating /var/lib/ca-certificates/ca-bundle.pem ... Expected Results: The Debian version of update-ca-certificates, which this is supposedly based on, outputs this: # update-ca-certificates Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d....done. With -v, it outputs the c_rehash output also. The Debian version does not rename the certs based on subject; since the SUSE version does, these should be listed, at least in verbose mode, e.g.: /etc/pki/trust/anchors/datanet.pem => /etc/ssl/certs/Organizational_CA.pem Certificates in /etc/ssl/certs are renamed based on the subject line of the input cert ('openssl x509 -noout -subject -in myCA.pem'), which can be confusing if the filename does not match the file in /etc/pki/trust/anchors. This is not documented anywhere, and combined with the lack of feedback, I thought my CA cert was being rejected, which in fact it was listed differently. (It had a subject "OU=Organizational CA, O=DATANET" and my filename was datanet.pem, but it gets stored in /etc/ssl/certs/Organizational_CA.pem.) This whole issue also applies to SLES 12 (except for missing release notes, which SLES 12 does have), which ships the same version of update-ca-certificates.