Project

General

Profile

Actions

Bug #6687

closed

Secure email fails with private CA

Added by Denny Page almost 6 years ago. Updated almost 3 years ago.

Status:
Duplicate
Priority:
Normal
Assignee:
-
Category:
Notifications
Target version:
-
Start date:
08/09/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:
All

Description

If a private CA such as a self signed enterprise CA is in use, the CA is not recognized when establishing SMTP connections even though the CA certificate has been imported in System / Certificate Manager / CAs.

The reason for this is that the imported CA certificate is not stored in a location/manner available to OpenSSL. One solution (there may be others) to this issue is to append imported CA certificates to /usr/local/share/certs/ca-root-nss.crt.

Actions #1

Updated by Kill Bill almost 6 years ago

Any attempts to do certificate validation here should be completely optional here (as in, a separate checkbox). Way too many mailservers have self-signed certificates or certificates that don't validate in one way or the other.

Actions #2

Updated by Denny Page almost 6 years ago

The concept of an option to ignore certificate validation is completely unrelated to this issue.

Actions #3

Updated by Ross Williams over 5 years ago

I am interested in implementing a related feature that allows a "private CA" to be installed as a trusted root that is validated against when performing package updates. Appending to the ca-root-nss.crt file gets the job done, but is bad(tm) because that file belongs to an installed package. The better solution is to create a directory under /usr/local/etc/ssl called /usr/local/etc/ssl/crt and then configure OpenSSL to look there for additional certs.

I'm imagining that putting the OpenSSL environment variables that cause cURL to use that certs directory at the earliest point possible in the init process would also cause most other OpenSSL-based applications to also look for additional certs. Is this still an issue for you, Denny?

Actions #4

Updated by Ross Williams over 5 years ago

The root issue appears to be #4068.

Actions #5

Updated by Jim Pingle almost 3 years ago

  • Category set to Notifications
  • Status changed from New to Duplicate

The root issue is definitely #4068, but an option was added to bypass this check in #9001 so this is a duplicate twice over.

Actions

Also available in: Atom PDF