Bug 62601 - Browser errors when generating mod_ssl test certs
Browser errors when generating mod_ssl test certs
Product: Red Hat Linux
Classification: Retired
Component: kdelibs (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Depends On:
Blocks: 61901
  Show dependency treegraph
Reported: 2002-04-02 17:50 EST by David Lawrence
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-08 15:10:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Lawrence 2002-04-02 17:50:52 EST
Description of Problem:
Browser generates error when accessing SSL enabled web site that had keys
generated manually with openssl commands.

Version-Release number of selected component (if applicable):

Steps to Reproduce:
1.  Generate key:
/usr/bin/openssl genrsa -out ssl.key/server.key 1024
2.  Generate cert request using supplied Makefile:
make certreq
3.  Bypass CA Authority generate certificate yourself
/usr/bin/openssl x509 -days 365 -signkey ssl.key/server.key -in
ssl.csr/server.csr -req -out ssl.crt/server.crt
4.  Restart web server

Actual Results:
Netscape 4.79 Browser Error: 
SSL has recieved an error from the server indicating an incorrect Message
Authentification Code. This could indicate a network error, a bad server
implementation, or a security violation.

Konquerer Generates error but complains that the certificate has expired. It
allows you to override
and still access the site. 

Expected Results:
Popup window asking if it is OK to accept the new certificate.

Additional Information:
The following errors are popping up in /var/log/httpd/ssl_engine_log

[02/Apr/2002 17:17:44 00726] [error] SSL handshake failed (server
dhcp59-205.rdu.redhat.com:443, client (OpenSSL library error
[02/Apr/2002 17:17:44 00726] [error] OpenSSL:

The following is the server.crt contents.
        Version: 1 (0x0)
        Serial Number: 0 (0x0)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=US, ST=North Carolina, L=Raleigh, O=Red Hat, Inc., OU=QA,
            Not Before: Apr  2 22:35:53 2002 GMT
            Not After : Apr  2 22:35:53 2003 GMT
        Subject: C=US, ST=North Carolina, L=Raleigh, O=Red Hat, Inc., OU=QA,
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                Exponent: 65537 (0x10001)
    Signature Algorithm: md5WithRSAEncryption
Comment 1 Nalin Dahyabhai 2002-04-05 04:08:56 EST
I'm unable to reproduce this with Netscape Communicator.

Try to reproduce this error dialog with Konqueror, then from the initial error
dialog, select "Details...", "Cryptography Configuration...", select the "Peer
SSL Certificates" tab, select the certificate for your test web site, and click
on the "Verify" button.  If it fails, press the "Details..." button for this
dialog and see if the resulting error message is the same.
Comment 2 David Lawrence 2002-04-05 11:16:38 EST
 Okay, I did what you suggested. First of all when Konqueror throws the error 
and I click in Details, one thing it does complain is that the certificate if 
expired. Here are the dates that it reports for a cert that I just created 5 
minutes before trying to us it. 
Certificate State: Certificate has expired 
Valid From: Friday 05 April 2002 04:08:04 GMT 
Valid Until: Saturday 05 April 2003 04:08:04 GMT 
That is odd. 
Then I have to force acceptance of the certificate once and then return to the 
Cryptography Configuration screen for the test cert to show up in the list. 
After hightlighting my test cert and clicking Verify, I get: 
This certificate has failed the tests and should be considered invalid.  
Clicking on details renders: 
Certificate is self signed and thus may not be trustworthy. 
This is different than the expired problem.
Comment 3 Nalin Dahyabhai 2002-04-05 12:57:57 EST
Because the timestamps are in GMT, the certificate is actually valid time-wise.
Because Netscape Communicator doesn't indicate that the certificate is expired,
but does prompt due to the signer being unknown, I suspect we're seeing a bug in
kdelibs's SSL-related code which causes an incorrect message to be displayed in
the first dialog, or the verification routine is not handling time zone
differences properly.
Comment 4 Nalin Dahyabhai 2002-04-05 15:48:20 EST
Confirmed: when validating certificates, kssl doesn't handle notBefore and
notAfter times properly unless the local time zone is GMT.  (The notBefore and
notAfter fields are GMT dates, and kssl uses the local time in its checks.)
Comment 5 David Lawrence 2002-04-05 15:56:19 EST
This doesnt really explain the Netscape 4.78 issue though.
Comment 6 Nalin Dahyabhai 2002-04-08 15:10:53 EDT
Dave, I couldn't reproduce this with the version of Netscape I had installed
(4.79-1).  I have just repeated the test with 4.78-2 and 4.78-1 and am still
unable to reproduce the failure.
Comment 7 Bernhard Rosenkraenzer 2002-04-10 12:33:49 EDT
This was fixed in kdelibs-3.0.0-7.
Comment 8 David Lawrence 2002-04-11 12:05:35 EDT
I feel this is now related to a time difference issue between the 
server/client. I have tried this with a different machine and have had 
success. I still get the Certificate has expired in Konqueror when clicking on 
the LOCK icon to view SSL details. The first screen you see shows 4:08 GMT but 
if you go to the Cryptography Configuration->Peel SSL Certificates screen and 
view the expiration date there it says 11:32 GMT instead of 4:08. Highlighting 
the test certificate and then clicking Verify only complains of the 
certificate being self-signed and not expired. Very strange. I wonder if Bero 
was saying this anomoly is what has been fixed in the latest kdelibs. 
In Netscape with the different server I am able to successfully accept the 
certificate with the obvious warning of it being self-signed also. 

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