This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 750408 - Cannot enable SSL
Cannot enable SSL
Status: CLOSED DUPLICATE of bug 740959
Product: Fedora
Classification: Fedora
Component: 389-ds (Show other bugs)
14
i686 Linux
unspecified Severity high
: ---
: ---
Assigned To: Rich Megginson
Fedora Extras Quality Assurance
: screened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-31 21:41 EDT by Maurice James
Modified: 2011-11-07 16:56 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-11-07 16:56:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Maurice James 2011-10-31 21:41:41 EDT
Description of problem:
When ever SSL is enables on a server it is unable to start via cli. Never prompted for password. The following error is produced:

[31/Oct/2011:21:31:22 -0400] - SSL alert: Security Initialization: Unable to authenticate (Netscape Portable Runtime error -8192 - An I/O error occurred during security authorization.)
[31/Oct/2011:21:31:22 -0400] - ERROR: SSL Initialization Failed.


Version-Release number of selected component (if applicable):
389-ds-1.2.2-1.fc14.noarch

How reproducible:
100% of the time

Steps to Reproduce:
1. request and load server certificate
2. restart dirsrv service
3.
  
Actual results:


Expected results:
server instance start up and ask for password

Additional info:
I tried using 2 different CA products:
TinyCA2 and DogTag PKI
Comment 1 Rich Megginson 2011-11-01 11:41:27 EDT
You used the 389-console to generate the cert request and install the cert from the CA?  The console currently has a bug - it installs the server cert in the admin server database instead of the directory server database.

See https://bugzilla.redhat.com/show_bug.cgi?id=740959

please confirm that the issue you are seeing is a duplicate of 740959 and that installing 389-admin-1.1.25 from updates-testing fixes your problem.
Comment 2 Maurice James 2011-11-01 20:46:30 EDT
That was exactly it. It worked after I updated the admin panel from the testing repo
Comment 3 Rich Megginson 2011-11-07 16:56:08 EST

*** This bug has been marked as a duplicate of bug 740959 ***

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