Bug 1236548
| Summary: | incorrect usage of system CA certs with wpa_supplicant | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Roman Kagan <rkagan> |
| Component: | NetworkManager | Assignee: | Lubomir Rintel <lkundrak> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 22 | CC: | awilliam, dcbw, lkundrak, psimerda, rkhan, thaller |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | NetworkManager-1.0.4-1.fc22 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-07-19 19:51:45 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Roman Kagan
2015-06-29 12:06:29 UTC
NetworkManager.spec contains "--with-system-ca-path=/etc/pki/tls/certs". As you wrote, the directory is used as ca_path option for wpa_supplicant that passes that to SSL_CTX_load_verify_locations(). And it doesn't work because Fedora uses certificate bundle files instead of directories with individual hashed certificates. There are quite extensive discussion about trusted certificate store and such. Reading through it, I seem to be unable to find out the best solution. I guess we could either specify ca_cert parameter for wpa_supplicant (https://w1.fi/cgit/hostap/tree/src/crypto/tls_openssl.c#n1792) as "/etc/pki/tls/cert.pem" instead of ca_path. The file is a link to the proper extracted certificates. /etc/pki/tls/cert.pem -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem Or, it might be better if wpa_supplicant used SSL_CTX_set_default_verify_paths(), which would cause using default OpenSSL trust store. Here are some interesting links: * bug 1053882 * bug 873373 * https://bugs.archlinux.org/task/43450 * https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/ * http://lists.shmoo.com/pipermail/hostap/2008-December/018936.html FWIW I'd say you're exactly right, Jirka - the ideal would be for wpa_supplicant to use SSL_CTX_set_default_verify_paths() (with the caveat that I believe it's used on Android and I haven't investigated at all whether that works on Android or not); otherwise, setting ca_path to /etc/pki/tls/ca-bundle.crt would be the preferred choice. I don't know if NM uses its setting for anything else, but it's notable that NM's configure script *only* allows you to specify a CA path, not a CA bundle file location. We do in fact have a directory in the expected format: /etc/pki/ca-trust/extracted/pem/directory-hash/ which we could point it to; I don't think it's terribly commonly used, but it ought to work. Note I have a proposal and patches in https://bugzilla.redhat.com/show_bug.cgi?id=1053882 to make ca-certificates provide /etc/ssl/certs in the hashed-directory format, which seems to have gotten stuck, no response from the maintainers lately. (In reply to Adam Williamson from comment #2) > the ideal would be for > wpa_supplicant to use SSL_CTX_set_default_verify_paths() Well the logic in wpa_supplicant is not so straightforward: currently if neither ca_path nor ca_file is given it opts not to verify certificates at all. So it'll probably need an extra option then to distinguish between no-verify and verify-with-default-certs. Anyway, as you point out, wpa_supplicant has broader usage than NM, so I thought it was easier for NM to adjust. > otherwise, setting ca_path to > /etc/pki/tls/ca-bundle.crt would be the preferred choice. No, ca_path is interpreted as a directory. It has to be ca_file pointing at this file (you mean /etc/pki/tls/cert.pem or /etc/pki/tls/certs/ca-bundle.crt, don't you?) > NM's configure script *only* allows you to specify a CA path, not a CA > bundle file location. It's not a big deal to test if it's given a file or a directory, and make up an appropriate option for wpa_supplicant. (Arguably it should have done so for 802-1x.ca-cert instead of creating 802-1x.ca-path, too, but it's to late now.) > We do in fact have a directory in the expected format: > > /etc/pki/ca-trust/extracted/pem/directory-hash/ Do we? Which package / version? Roman: please make all obvious corrections to any emails I send before 8am. ;) Yes, I meant ca_file and /etc/pki/tls/certs/ca-bundle.crt . "Do we? Which package / version?" [referring to /etc/pki/ca-trust/extracted/pem/directory-hash/] Ah, crap - I just realized that's part of my patch posted in #1053882, not part of current ca-certificates. Sorry, I forgot. So indeed, current official ca-certificates does not provide a hashed directory, only bundle files. I was not able to find /etc/pki/ca-trust/extracted/pem/directory-hash/ too. That's a pity it is not there. So I think the easiest way is to enhance 'with_system_ca_path' in NetworkManager to allow either a directory or a filename. And in the latter case, NM will populate wpa_supplicant's ca_cert instead of ca_path. I pushed a branch with the fix upstream: jk/system-ca-certs-rh1236548 Fedora 22 NetworkManager test build: http://koji.fedoraproject.org/koji/taskinfo?taskID=10259225 LGTM Committed upstream: master: 640eb8f supplicant: allow with_system_ca_path to be a file name (rh #1236548) nm-1-0: c73eeb3 supplicant: allow with_system_ca_path to be a file name (rh #1236548) This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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 Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. This would've been fixed at some point as an update was submitted, so let's change resolution to ERRATA. |