Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

trust pem file misparsed #205

Closed
ametzler opened this issue Dec 22, 2018 · 4 comments
Closed

trust pem file misparsed #205

ametzler opened this issue Dec 22, 2018 · 4 comments

Comments

@ametzler
Copy link

Hello,

this is https://bugs.debian.org/914199 submitted by Sam Morris:
XXXXXXXX Quote
$ grep BEGIN /etc/ssl/certs/ca-certificates.crt | wc -l
154

$ trust list; echo $0
0

That's from p11-kit 0.23.14-2. If I use the version from stable there is at
least a clue that something is amiss:

# trust list; echo $?
p11-kit: ca-certificates.crt: BEGIN ...: pem block before p11-kit section header
p11-kit: ca-certificates.crt: BEGIN ...: pem block before p11-kit section header
0

It turns out that, in-between the PEM-encoded certificates in
ca-certificates.crt, I have some lines:

...
-----END CERTIFICATE-----
# This file was created by IPA. Do not edit.

[p11-kit-object-v1]
class: certificate
certificate-type: x-509
certificate-category: authority
label: "CN%3Dipa-CA%2CDC%3Dipa%2CDC%3Dexample%2CDC%3Dcom"
subject: "..."
issuer: "..."
serial-number: "..."
x-public-key-info: "..."
trusted: true
-----BEGIN CERTIFICATE-----
...

These are in turn taken from the file that ipa-client-install dropped into
/usr/local/share/ca-certificates/ipa-ca.crt.

IMO p11-kit should treat these extra lines as comments since other tools
(openssl, gnutls) are perfectly happy to ignore them.

It would also be nice if it printed some more useful output to help users
debug issues such as these, and not exit with status 0 if problems are
detected. :)
XXXXXXXX End Quote

On Debian p11-kit is configured with --with-trust-paths=/etc/ssl/certs/ca-certificates.crt. Looking at the documentation for the trust module https://p11-glue.github.io/p11-glue/p11-kit/manual/trust-module.html afaict p11-kit should indeed interpret these as RFC 7468 PEM files, ignoring anything outside BEGIN/END markers.

@ueno
Copy link
Member

ueno commented Dec 22, 2018

I would say this is an expected behavior. The trust module recognizes the file format in the following order: the p11-kit persistent file format, DER, and PEM. So if it found the marker ([p11-kit-object-v1]), it treats the entire file as a p11-kit persistent file.

Re warning message: it was turned off by f992eb6. You can still see it when you set P11_KIT_DEBUG=all. We can certainly make trust list more verbose, but it's not trivial because the message comes from the trust module.

@ametzler
Copy link
Author

ueno commented

I would say this is an expected behavior. The trust module recognizes the file format in the following order: the p11-kit persistent file format, DER, and PEM. So if it found the marker ([p11-kit-object-v1]), it treats the entire file as a p11-kit persistent file.

Afaict this behavior does not match the documentation:

Files in the following formats are supported for loading by the trust policy module:

  • X.509 certificates | X.509 certificates in raw DER format. [...]
  • PEM certificates | X.509 certificates in PEM format. These have a BEGIN CERTIFICATE header. [...]
  • OpenSSL trust certificates | OpenSSL specific certificates in PEM format that contain trust information. These have a BEGIN TRUSTED CERTIFICATE PEM header. [...]

@ueno
Copy link
Member

ueno commented Dec 23, 2018

I know. I meant that it could be only fixed by updating the documentation.

@ueno
Copy link
Member

ueno commented Dec 25, 2018

After a second thought, it is actually possible to fall back to PEM blobs if the file is not parsable as p11-kit persistent format. I have updated the linked PR to cover this.

@ueno ueno closed this as completed in #206 Jan 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants