Re: no start line
On Tue, Nov 09, 1999, [EMAIL PROTECTED] wrote: You have not mentioned where you put your private key by using the directive SSLCertificateKeyFile. Have you placed your keyfile to an appropriate place and pointed SSLCertificateKeyFile to this file. Note that mod_ssl does not complain about the certificate, but about the key file. Maybe that's your problem. [...] [Tue Nov 9 14:30:46 1999] [crit] (2)No such file or directory: mod_ssl: Failed to read private key file /etc/httpd/mycert.pem [Tue Nov 9 14:30:46 1999] [error] SSLeay: error:0906D06C:PEM routines:PEM_read_bio:no start line Ops, good catch. Yes, _THAT_ is the users problem. He hasn't configured SSLCertificateKeyFile and so mod_ssl asumes it can find the private key in the same file where the certificate is stored. The user has to add a SSLCertificateKeyFile directive to the private key Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: no start line
On Tue, Nov 09, 1999, Chris Ingrassia wrote: On Tue, 9 Nov 1999, R. DuFresne wrote: you apaches is 6 revs old, I think yer open ssl is a rev or two old, I'm betting yer suse linux is also old and lacking many significant updates and fixes. I'd advise first off that you upgrade it all to something more current and stable. Actually the apache is only 2 public releases old, and the openssl (version 0.9.4) is current. The OpenSSL version 0.9.4 is current, but because mod_ssl uses the "SSLeay" tag in the logfile this indicates that this OpenSSL version wasn't used for compiling Apache and mod_ssl! mod_ssl uses the SSLeay tag only for approx. SSLeay/OpenSSL = 0.9.0. So, the version which is actually compiled in _is_ old ;) Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: SSL handshake failed
On Tue, Nov 09, 1999, Robert Flemming wrote: [...] routines:RSA_padding_check_PKCS1_type_2:block type is not 02 [error] OpenSSL: error:04065072:rsa routines:RSA_EAY_PRIVATE_DECRYPT:padding check failed [error] OpenSSL: error:1408F071:SSL routines:SSL3_GET_RECORD:bad mac decode If anyone has any thoughts or tips on the matter I'd greatly appreciate them. I've not had this problem before, but I've never used this combination of versions either. I'm I just missing something stupid or is a genuine problem? In 90% of all cases where one receives this error this was caused by a cached old certificate/key information in the browser. And one can get rid of the error by just removing all cached cert/keys in the browsers security dialogs. Typical error is that the browser remembers a certificate, one recreates one (usually especially the Snake Oil cert) and then one retries it. Then although the cert's DN is still the same, the ingredients are not. Then this causes exactly the above error. So check your browsers security dialog for cached/remembered certs of your server. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: SSL handshake failed
"Ralf S. Engelschall" wrote: In 90% of all cases where one receives this error this was caused by a cached old certificate/key information in the browser. And one can get rid of the error by just removing all cached cert/keys in the browsers security dialogs. Typical error is that the browser remembers a certificate, one recreates one (usually especially the Snake Oil cert) and then one retries it. Then although the cert's DN is still the same, the ingredients are not. Then this causes exactly the above error. So check your browsers security dialog for cached/remembered certs of your server. I had seen this in a previous message on the list and had removed any reference to the server I was working on. I didn't think that it could have been one from a totally different server. Someone else set up another machine here similarly and it was the certificate for that _other_ machine that was causing this one to vomit. So of course removing that certificate and accessing my server then worked fine, and accessing the other would now fail. I should have tried that earlier, my bad. Thanks for the help. Robert __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Dilemma, Apache versions FrontPage
yer dilema is worse then ya think, add frontpage extensions only if this server is on the DMZ and you are willing to sacrifice it and reinstall from backups often. Thanks, Ron DuFresne On Wed, 10 Nov 1999, Mark Jaffe wrote: I have been requested by one of my clients to support FrontPage extensions on my MkLinux box currently running Apache-1.3.6 and mod_ssl 2.3.4 The FrontPage extensions patches are for 1.3.6 Apache only. Current mod_ssl 2.4.8 is for apache_1.3.9. What should I do: stay at current apache and mod_ssl or try to move forward to newer apache mod_ssl and risk breaking FrontPage? Does anyone run FrontPage extensions on non-intel servers such as LinuxPPC or MkLinux? Mark Mark Jaffe| (408) 972-9638 (home) Chief Wizard | (408) 529-1926 (cell/page/voicemail) Computer Wizards | (408) 364-4484 (work @ RSV ) [EMAIL PROTECTED]| http://www.wizdev.net/ __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] -- ~~ admin senior consultant: darkstar.sysinfo.com http://darkstar.sysinfo.com "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart testing, only testing, and damn good at it too! __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Bad Mac Decode?
Hi all, I'm on RH 6.1, Apache 1.3.9, modssl 2.4.8-1.3.9, and openssl 0.9.4. When I attempted to establish a secure connection, my Netscape browser complained about an incorrect "Message Authentication Code." The end of ssl_engine_log looks like this: [10/Nov/1999 20:47:25 25706] [info] Connection to child 3 established (server blah.com:443, client 12.34.56.78) [10/Nov/1999 20:47:25 25706] [error] SSL handshake failed (server blah.com:443, client 12.34.56.78) (OpenSSL library error follows) [10/Nov/1999 20:47:25 25706] [error] OpenSSL: error:0407106B:rsa routines:RSA_padding_check_PKCS1_type_2:block type is not 02 [10/Nov/1999 20:47:25 25706] [error] OpenSSL: error:04065072:rsa routines:RSA_EAY_PRIVATE_DECRYPT:padding check failed [10/Nov/1999 20:47:25 25706] [error] OpenSSL: error:1408F071:SSL routines:SSL3_GET_RECORD:bad mac decode Can anybody help me? This looks like an openssl problem, but I was able to make this same build of openssl run fine under Apache 1.3.6 with mod_ssl-2.3.11-1.3.6. This factor focuses my suspicions on this new version of modssl. Here's some background, if needed: I downloaded and untarred the sources. Moving to openSSL, I did: ./configure make make test Everything looked good. I then moved to mod_SSL and did: ./configure --with-apache=../apache_1.3.9 --with-ssl=../openssl-0.9.4 --prefix=/usr/local/apache Looked fine. Then I moved to the apache source and did: make make certificate (I kept all the www.snakeoil.com defaults) make install Everything looked good. I was able to do this successfully with Apache 1.3.6 (and the appropriate mod_ssl version), but 1.3.9 is giving me fits. The rest of the server (e.g. non-encrypted stuff) runs fine. Any ideas? Thanks, Steve Freitas __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Long connect times...
I'm clearly a stupid fsck, but perhaps this tip will help other stupid fscks out there running Apache and modssl on Linux. I was having trouble with long (really long, sometimes) connect times on SSL connections. Sometimes things would go through immediately, or within a second or two, but often it would be 20 seconds before data started coming back. Well, I'd configured SSL to use the high-quality random data from /dev/random (Linux gurus can stop reading here -- I've just told you what I did wrong) but that device won't give you any more data than it has collected entropy. That is, /dev/random maintains a pool of randomness that is fed by external, presumably unpredictable, events. When the pool runs dry, you have to wait for some random stuff to happen before you'll get the data you tried to read. So Apache was reading from this limited resource, and sometimes (if I was moving the mouse, or typing, or had a lot of disk activity happening) there'd be enough random data to generate a key or whatever modssl needed, but other times it had to wait until "things" happened. Tough to debug if you're thinking it's maybe network problems or something, but a quick strace will show what's really happening. Anyway, the solution is to use /dev/urandom, which never runs dry, as your source for the SSLRandomSeed lines. d. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: ca and certs
hUnTeR schrieb: Well i did do a ton of reading, and yes even tried the CA.pl(sh) script. What it turned out to be, just for anyone else that is curious, is that the Location (city) needed to be different between the CA and the server cert itself. Once i made that one and only change, it all works well. I minor comment: the diffeent location's name is not the problem. It probably should read "The distinguished names (that is all the details you enter while generating the request) must be different for the CA and the server cerst. Usually this should already be fullfilled with the common name (CN) beeing different: the server cert should have the host name in it, the CA usually something different." -- Holger Reif Tel.: +49 361 74707-0 SmartRing GmbH Fax.: +49 361 7470720 Europaplatz 5 [EMAIL PROTECTED] D-99091 ErfurtWWW.SmartRing.de __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
