Bug 806959
| Summary: | certificate key usage is displayed wrong | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mr-4 <mr.dash.four> |
| Component: | openvpn | Assignee: | Steven Pritchard <steve> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | davids, gwync, huzaifas, psabata, steve |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-13 22:27:35 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Any movement on this? This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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. Thank you for reporting this bug and we are sorry it could not be fixed. |
Description of problem: When openvpn displays certificate key usage, it displays it wrong. For example, if I have "digitalSignature and keyAgreement" bits on, then openvpn interprets this as 0x88, which is wrong (see below). Version-Release number of selected component (if applicable): 2.2.1, but also 2.2.2 (the latest stable) How reproducible: Always Steps to Reproduce: 1. run openvpn with --remote-cert-tls option enabled 2. 3. Actual results: Something like this in the logs (server side): Mon Mar 26 14:36:55 2012 xx Validating certificate key usage Mon Mar 26 14:36:55 2012 xx ++ Certificate has key usage 0088, expects 0080 Mon Mar 26 14:36:55 2012 xx ++ Certificate has key usage 0088, expects 0008 Mon Mar 26 14:36:55 2012 xx ++ Certificate has key usage 0088, expects 0088 In other words, it interprets bit 0 (digitalSignature) and bit 4 (keyAgreement) wrong as 0x88 hex, when it should be interpreted (and displayed) as 0x11 hex. Expected results: Mon Mar 26 14:36:55 2012 xx Validating certificate key usage Mon Mar 26 14:36:55 2012 xx ++ Certificate has key usage 0011, expects 0010 Mon Mar 26 14:36:55 2012 xx ++ Certificate has key usage 0011, expects 0001 Mon Mar 26 14:36:55 2012 xx ++ Certificate has key usage 0011, expects 0011 Additional info: According to Section 4.2.1.3 of RFC3280, the certificate key usage is defined as follows: KeyUsage ::= BIT STRING { digitalSignature (0), nonRepudiation (1), keyEncipherment (2), dataEncipherment (3), keyAgreement (4), keyCertSign (5), cRLSign (6), encipherOnly (7), decipherOnly (8) } In other words, the values of digitalSignature (bit 0 - 0x01 hex, 00000001 binary) and/or keyAgreement (bit 4 - 0x10 hex, 0001 0000 binary), when OR-ed should give me the following numbers for the certificate key usage: 0x01 (0000 0001), 0x10 (0001 0000) or 0x11 (0001 0001), not 0x80 (1000 0000) 0x08 (0000 1000) or 0x88 (1000 1000). Similar for the server: bit 0 and (bit 2 or bit 4) makes this as 0x5 (0000 0101) or 0x11 (0001 0001), not 0xa0 (1010 0000) or 0x88 (1000 1000). Not only is the interpretation of the above wrong, but the openvpn man pages as well as the on-line manual is also incorrect, as it states that the predefined certificate key usage for clients is "80 08 88" - "digitalSignature and/or keyAgreement". The same for the server - "a0 88" when "digitalSignature and ( keyEncipherment or keyAgreement )" is used.