Bug 1160172 - [RFE] openssl 1.0.1e-fips 11 Feb 2013 does not allow validation of common name against host name
[RFE] openssl 1.0.1e-fips 11 Feb 2013 does not allow validation of common nam...
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: openssl (Show other bugs)
rawhide
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks: 864897
  Show dependency treegraph
 
Reported: 2014-11-04 03:56 EST by pjp
Modified: 2014-11-04 07:39 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-11-04 07:39:45 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description pjp 2014-11-04 03:56:39 EST
Description of problem:

With current openssl version 1.0.1e-fips 11 Feb 2013, it is not possible to ensure that the certificate is actually issued for the server in question. i.e. by verifying the common name against the host name. This can be easily done with OpenSSL 1.1, but older releases require to do this in the application. Therefore the code from OpenSSL 1.1 needs to be back ported to the older OpenSSL in Fedora or into ssmtp itself.

Please see -> https://bugzilla.redhat.com/show_bug.cgi?id=864897#c12

Could this support be provided in older version of Openssl? Or should applications handle it at their end?

Thank you.
Comment 1 Tomas Mraz 2014-11-04 04:03:24 EST
I don't think it makes much sense to backport this support as it would be impossible for applications to depend on it anyway unless the support is backported in all the major distributions. So that basically means that applications have to handle this by themselves anyway.

Once the upstream package with the new API is released, we will rebase in Fedora as well.
Comment 2 pjp 2014-11-04 05:12:45 EST
(In reply to Tomas Mraz from comment #1)
> impossible for applications to depend on it anyway unless the support is
> backported in all the major distributions.

  Well, at least packages in Fedora would be able to use it, no?

> Once the upstream package with the new API is released, we will rebase in
> Fedora as well.

  Don't we push the latest upstream release as is? Why rebase? (just checking)

Thank you.
Comment 3 Tomas Mraz 2014-11-04 05:29:05 EST
We have multiple patches on top of the upstream version so that's why it is called rebase.

Even if on Fedore the apps could use the API they would still need to implement their own checking as the API would not be universally present so except for Fedora only apps, this feature would not help much.
Comment 4 pjp 2014-11-04 07:22:55 EST
I see. Well, I was thinking of an universal upstream fix and not a Fedora specific one. Are you in contact with the upstream developers? Could you please let them know about? For the packages I maintain I usually send such requests to upstream developers.
Comment 5 Tomas Mraz 2014-11-04 07:39:45 EST
There is a clear policy of patch addition and maintenance of upstream version branches so there is no chance of such backport to have an official upstream status.

Note You need to log in before you can comment on or make changes to this bug.