RE: MSIE *Again*
William, That *DID* workdo you happen to have any explaination as to why? It doesn't make sense that having to turn on revocation checking would allow it to work? Is this true for all Verisign certs? If so, why do I not get that error when going to other sites with a Verisign cert using IE? - Bob -Original Message- From: Wallace, William [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 27, 2000 10:17 AM To: '[EMAIL PROTECTED]' Subject: RE: MSIE *Again* Does changing the "Check for server certificate revocation (requires restart)" advanced security setting in IE change the behavior? -Original Message- From: Burns, Robert [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 26, 2000 10:38 AM To: '[EMAIL PROTECTED]' Subject: MSIE *Again* Folks, I believe I'm experiencing the same MSIE problems that have been discussed on this list over the past few weeks, but with a little more information. Perhaps it will help. I'm running Apache 1.3.12 + modssl 2.6.4 + openssl 0.9.5a on an UltraSparc 10 + Solaris7. First, I created a dummy certificate (i.e. signed by Snake-Oil CA) and everything works just fine. Both IE and Netscape connect without incident. Next, I got a generated new keys and got a Verisign certificate. I installed this certificate (along with the intermediate certificate) and that's when things started breaking for IE only. Netscape will connect just fine, but IE gives that 'very informative' error screen. Here is the tail end of the log with debug turned on: [26/Jul/2000 09:55:20 27052] [debug] OpenSSL: write 67/67 bytes to BIO#0014D048 [mem: 001749F0] (BIO dump follows) +- + | : 14 03 00 00 01 01 16 03-00 00 38 7c 9b f8 cc 94 ..8| | | 0010: 73 0a b9 2b e8 ec 32 91-c2 88 86 52 2b d6 f3 12 s..+..2R+... | | 0020: 8c 67 0d 7a f9 c2 0c 1e-4c c8 6d 7a 95 3e 21 d9 .g.zL.mz.!. | | 0030: 02 16 c0 7d 94 4d 47 7d-70 49 9a 4c d6 db 82 c9 ...}.MG}pI.L | | 0040: 72 09 17 r.. | +- + [26/Jul/2000 09:55:20 27052] [trace] OpenSSL: Loop: SSLv3 flush data [26/Jul/2000 09:55:20 27052] [trace] Inter-Process Session Cache: request=SET status=OK id=460730715DA5C519241676A466979A8EC3B3813DC8A8803C81BCA4658A094BD8 timeout=299s (session caching) [26/Jul/2000 09:55:20 27052] [trace] OpenSSL: Handshake: done [26/Jul/2000 09:55:20 27052] [info] Connection: Client IP: 192.168.8.109, Protocol: SSLv3, Cipher: RC4-MD5 (128/128 bits) [26/Jul/2000 09:55:20 27052] [debug] OpenSSL: read 0/18437 bytes from BIO#0014D048 [mem: 001675C8] (BIO dump follows) +- + +- + [26/Jul/2000 09:55:20 27052] [debug] OpenSSL: write 23/23 bytes to BIO#0014D048 [mem: 0016FDD8] (BIO dump follows) +- + | : 15 03 00 00 12 d4 c5 65-6a a4 01 3f bd 11 49 75 ...ej..?..Iu | | 0010: 12 43 94 83 8f 2c a5 .C...,. | +- + [26/Jul/2000 09:55:20 27052] [trace] OpenSSL: Write: SSL negotiation finished successfully [26/Jul/2000 09:55:20 27052] [info] Connection to child 1 closed with standard shutdown (server 192.168.8.84:443, client 192.168.8.109) It appears that in the line above (read 0/18437 bytes from...) that IE shutdown the TCP/IP connection, forcing the SSL connection to be closed by the server. The question is, why does IE shutdown the connection, but Netscape continued on without problem? I'm going to try to sniff the TCP line to see what is actually happening, but until then, any additional insight would be helpfull. Thanks, - Bob -- Bob BurnsZaxus [EMAIL PROTECTED] 1-888-744-4976, X6510 (local) 1-954-846-6510 -- __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Running Mod_ssl when starting apache automatically.
I found a couple of sections in the archives stating that the way to do this was to remove the passphrase section of the key. Is there a way to automatically start the ./apachectl startssl and have it pickup the passphrase from a file or script or something. I have so far had no luck trying either of these approaches as it seems to require keyboard input to take the passphrase. Any and all input is greatly appreciated. Gene Lamoreaux Systems Integration Engineer Syndeo Corporation Office:(408) 861-1000 Ext.5002 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Problem with Failed to generate temporary 512 bit RSA private key
Hello I have just installed mod-ssl on a solaris /sparc machine and get the above error. I have read the FAQ and tried to following what it is suggesting with $HOME/.rnd but do not quite follow it - well what I did, did not work. I have also tried truerand as well but that did not work either. Please advise Simon. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: apache+modssl+... got SEGVs
On Wed, Jul 26, 2000 at 11:17:14AM +0200, Hugues Pisapia wrote: And sometimes (well, more often with MSIE than with Mozilla :), apache gets Segmentation faults. It seems that it comes from openssl or modssl as i tried many configurations. Apache gets SEGVs only when the virtual host with modssl is running. I tried many thing to figure out where it comes from, but i have no more idea... Could someone help me, at least to give me a clue ? Last things : i tried the solution in the FAQ, i.e. to change the SSLSessionCache directive arguments, but i'm running apache from a rpm, so i don't have mm support, and my project manager will kick me if i say that i have to recompile apache :/, so i'd like to avoid that. No one has had good luck when using RPMs to install mod_ssl. I'm afraid that recompiling Apache from scratch is the way to go. Why will your project manager kick you for recompiling Apache? You'll only be down for a second or two when you install the newly compiled Apache. -Dave __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: starting ssl
On Fri, Jul 28, 2000 at 01:27:32PM +0800, Raymond wrote: thanks for the reply david but that did not work also. any other suggestions. Can you make your config file available somewhere so we can take a look at it? I've most often found that config file problems are the most frequent cause of your problem. Any reason you're not using the apachectl script to start/stop Apache? -Dave __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
FW: Re: verisign certificate installation
Hi, I've clicked "Reply via email to Victor" but unfortunately mail bounced back . Thanks and Regards, Myint Myint Moe -Original Message- From: Myint Myint Moe Sent: Friday, July 28, 2000 6:42 PM To: '[EMAIL PROTECTED]' Subject: Re: verisign certificate installation Hi, Thanks for your reply. In Apache-modssl, httpd.conf also have the following directive lines and default is making comment that lines. # Client Authentication (Type): # Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a # number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid. #SSLVerifyClient require #SSLVerifyDepth 10 Shall I remark-out and set SSLVerifyClient none SSLVerifyDepth 10 [none: no client Certificate is required at all optional: the client may present a valid Certificate require: the client has to present a valid Certificate optional_no_ca: the client may present a valid Certificate but it need not to be (successfully) verifiable] Please advise me and also other directive variable need to set (e.g SSLCACertificatePath and etc).Currently all lines with comments except SSLCertificateFile SSLCertificatekeyFile directive lines. (I'm quite new in SSL setting and server cannot be start and stop frequently. I'm waiting your favorable reply.) Thanks in advance. Regards, Myint Myint Moe __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
FW: Re: verisign certificate installation
Hi, I've clicked "Reply via email to Victor" but unfortunately mail bounced back . Thanks and Regards, Myint Myint Moe -Original Message- From: Myint Myint Moe Sent: Friday, July 28, 2000 6:42 PM To: '[EMAIL PROTECTED]' Subject: Re: verisign certificate installation Hi, Thanks for your reply. In Apache-modssl, httpd.conf also have the following directive lines and default is making comment that lines. # Client Authentication (Type): # Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a # number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid. #SSLVerifyClient require #SSLVerifyDepth 10 Shall I remark-out and set SSLVerifyClient none SSLVerifyDepth 10 [none: no client Certificate is required at all optional: the client may present a valid Certificate require: the client has to present a valid Certificate optional_no_ca: the client may present a valid Certificate but it need not to be (successfully) verifiable] Please advise me and also other directive variable need to set (e.g SSLCACertificatePath and etc).Currently all lines with comments except SSLCertificateFile SSLCertificatekeyFile directive lines. (I'm quite new in SSL setting and server cannot be start and stop frequently. I'm waiting your favorable reply.) Thanks in advance. Regards, Myint Myint Moe __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
[BugDB] compiling mod_ssl without EAPI (PR#435)
Full_Name: Dimulka Version: 0.9.5a OS: Solaris Submission from: (NULL) (193.232.88.16) Hi all! I need to compile apache with mod_ssl with plain API but after configurin' mod_ssl EAPI is enabled even if I use '--disable-rule=EAPI' option. And after runnin' apache I have got an error message like this: "[Fri Jul 28 16:21:53 2000] [warn] Loaded DSO some_module.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI)" What have I to do to avoid this warning? __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
RE: MSIE *Again*
Sorry Robert, I don't have any explaination. I discovered the same problem mid-June and have only just got around to investigating it. I've done the same SSL log analysis as you and a packet trace as well. At the packet level what happens is as soon as the handshake completes IE closes the connections (it sends a FIN). It seems to only happen with the X509 v3 certificates from Verisign so perhaps it's something to do with the x509 version or the fact that their v3 certificates have an additional certificate in the chain. I've seen similar certificates work though with IE (but a different web server). On a somewhat wierd note, we both have famous Scottish names! -Original Message- From: Burns, Robert [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 27, 2000 10:33 AM To: '[EMAIL PROTECTED]' Subject: RE: MSIE *Again* William, That *DID* workdo you happen to have any explaination as to why? It doesn't make sense that having to turn on revocation checking would allow it to work? Is this true for all Verisign certs? If so, why do I not get that error when going to other sites with a Verisign cert using IE? - Bob -Original Message- From: Wallace, William [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 27, 2000 10:17 AM To: '[EMAIL PROTECTED]' Subject: RE: MSIE *Again* Does changing the "Check for server certificate revocation (requires restart)" advanced security setting in IE change the behavior? -Original Message- From: Burns, Robert [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 26, 2000 10:38 AM To: '[EMAIL PROTECTED]' Subject: MSIE *Again* Folks, I believe I'm experiencing the same MSIE problems that have been discussed on this list over the past few weeks, but with a little more information. Perhaps it will help. I'm running Apache 1.3.12 + modssl 2.6.4 + openssl 0.9.5a on an UltraSparc 10 + Solaris7. First, I created a dummy certificate (i.e. signed by Snake-Oil CA) and everything works just fine. Both IE and Netscape connect without incident. Next, I got a generated new keys and got a Verisign certificate. I installed this certificate (along with the intermediate certificate) and that's when things started breaking for IE only. Netscape will connect just fine, but IE gives that 'very informative' error screen. Here is the tail end of the log with debug turned on: [26/Jul/2000 09:55:20 27052] [debug] OpenSSL: write 67/67 bytes to BIO#0014D048 [mem: 001749F0] (BIO dump follows) +- + | : 14 03 00 00 01 01 16 03-00 00 38 7c 9b f8 cc 94 ..8| | | 0010: 73 0a b9 2b e8 ec 32 91-c2 88 86 52 2b d6 f3 12 s..+..2R+... | | 0020: 8c 67 0d 7a f9 c2 0c 1e-4c c8 6d 7a 95 3e 21 d9 .g.zL.mz.!. | | 0030: 02 16 c0 7d 94 4d 47 7d-70 49 9a 4c d6 db 82 c9 ...}.MG}pI.L | | 0040: 72 09 17 r.. | +- + [26/Jul/2000 09:55:20 27052] [trace] OpenSSL: Loop: SSLv3 flush data [26/Jul/2000 09:55:20 27052] [trace] Inter-Process Session Cache: request=SET status=OK id=460730715DA5C519241676A466979A8EC3B3813DC8A8803C81BCA4658A094BD8 timeout=299s (session caching) [26/Jul/2000 09:55:20 27052] [trace] OpenSSL: Handshake: done [26/Jul/2000 09:55:20 27052] [info] Connection: Client IP: 192.168.8.109, Protocol: SSLv3, Cipher: RC4-MD5 (128/128 bits) [26/Jul/2000 09:55:20 27052] [debug] OpenSSL: read 0/18437 bytes from BIO#0014D048 [mem: 001675C8] (BIO dump follows) +- + +- + [26/Jul/2000 09:55:20 27052] [debug] OpenSSL: write 23/23 bytes to BIO#0014D048 [mem: 0016FDD8] (BIO dump follows) +- + | : 15 03 00 00 12 d4 c5 65-6a a4 01 3f bd 11 49 75 ...ej..?..Iu | | 0010: 12 43 94 83 8f 2c a5 .C...,. | +- + [26/Jul/2000 09:55:20 27052] [trace] OpenSSL: Write: SSL negotiation finished successfully [26/Jul/2000 09:55:20 27052] [info] Connection to child 1 closed with standard shutdown (server 192.168.8.84:443, client 192.168.8.109) It appears that in the line above (read 0/18437 bytes from...) that IE shutdown the TCP/IP connection, forcing the SSL connection to be closed by the server. The question is, why does IE shutdown the connection, but Netscape continued on without problem? I'm going to try to sniff the
Re: : apache+modssl+... got SEGVs
On Fri, Jul 28, 2000 at 02:07:51AM -0700, David Rees wrote: On Wed, Jul 26, 2000 at 11:17:14AM +0200, Hugues Pisapia wrote: And sometimes (well, more often with MSIE than with Mozilla :), apache gets Segmentation faults. It seems that it comes from openssl or modssl as i tried many configurations. Apache gets SEGVs only when the virtual host with modssl is running. I tried many thing to figure out where it comes from, but i have no more idea... Could someone help me, at least to give me a clue ? Last things : i tried the solution in the FAQ, i.e. to change the SSLSessionCache directive arguments, but i'm running apache from a rpm, so i don't have mm support, and my project manager will kick me if i say that i have to recompile apache :/, so i'd like to avoid that. The RPMs at modssl.org have mm compiled in. No one has had good luck when using RPMs to install mod_ssl. I'm afraid that recompiling Apache from scratch is the way to go. What's the problem with the RPMs? I roll them, and if you got a RPM specific porblem, I'll be happy to look at it. Why will your project manager kick you for recompiling Apache? You'll only be down for a second or two when you install the newly compiled Apache. Maintenence? It's easier with RPMs... /magnus -Dave __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] -- Magnus Stenman mailto:[EMAIL PROTECTED] http://www.hkust.se Get it up, keep it up. Linux -- Viagra for your PC __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: : apache+modssl+... got SEGVs
No one has had good luck when using RPMs to install mod_ssl. I'm afraid that recompiling Apache from scratch is the way to go. What's the problem with the RPMs? I roll them, and if you got a RPM specific porblem, I'll be happy to look at it. Maybe if everyone used the RPMs you rolled there wouldn't be any problems, but it seems that people want to take one RPM from every site, throw them all together, and hope they work. Then they don't because one package wasn't compiled with the right options (like EAPI) There just seems to be too many variables if you want to use RPMs to build Apache/mod_ssl, especially since a lot of people would also like to use RPMs to install other Apache modules I'm sure (php, mod_perl). It also seems that a lot of the people that come to the list reporting Apache/mod_ssl crashes are using RPMs. Why will your project manager kick you for recompiling Apache? You'll only be down for a second or two when you install the newly compiled Apache. Maintenence? It's easier with RPMs... Can't argue with you there. -Dave __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Frames Javascript - insecure?
Hi Everyone, I've searched the archives and FAQ for the answer to this, to no avail. I have a page on my site that has one frameset with two frames, one of which is a frameset with two more frames (yah, i know, frames are evil yadda yadda). The outermost frameset is called with a secure URL, and all of the frame src="..." tags use only relative URIs. Nevertheless, when viewed on IE the page gives the warning "this page contains both secure and insecure elements" - it's not an IE specific bug, as Netscape's security summary says the same thing - listing the individual page elements in Netscape shows that it thinks that the html pages, all of which it correctly lists as https://whatever have: Security: Status unknown One of the frames does use Javascript (ya, i know, javascript is as evil as frames, yadda yadda) extensively to write to another frame; I don't know if it's the frames or the Javascript (or something completely different?) that's causing this problem... which is why I'm coming here for advice :) TIA, Lee __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Frames Javascript - insecure?
[EMAIL PROTECTED] 07/28/00 12:12PM The outermost frameset is called with a secure URL, and all of the framesrc="..." tags use only relative URIs. Nevertheless, when viewed on IEthe page gives the warning "this page contains both secure and insecureelements" - it's not an IE specific bug, as Netscape's security summarysays the same thing - listing the individual page elements in Netscapeshows that it thinks that the html pages, all of which it correctly listsas https://whatever have: You get this if ANY of the elements of the page (eg, images) are delivered via an insecure method (http://, file://, etc). Make sure that*all* images are delivered via HTTPS along with the HTML documents, and the error should go away. The javascript ought not matter. Hope this helps, --Cliff Cliff WoolleyCentral Systems Software AdministratorWashington and Lee Universityhttp://www.wlu.edu/~jwoolley/ Work: (540) 463-8089Pager: (540) 462-2303
Re: Frames Javascript - insecure?
I did check everything, and everything is being served via HTTPS (everything is specified relative to the main frameset pages, which are all https). In fact, Netscape lists the individual images as being secure, but all of the .html components of the page are listed as 'Status unknown'. Thanks for the suggestion, though, Lee On Fri, 28 Jul 2000, Cliff Woolley wrote: [EMAIL PROTECTED] 07/28/00 12:12PM The outermost frameset is called with a secure URL, and all of the frame src="..." tags use only relative URIs. Nevertheless, when viewed on IE the page gives the warning "this page contains both secure and insecure elements" - it's not an IE specific bug, as Netscape's security summary says the same thing - listing the individual page elements in Netscape shows that it thinks that the html pages, all of which it correctly lists as https://whatever have: You get this if ANY of the elements of the page (eg, images) are delivered via an insecure method (http://, file://, etc). Make sure that *all* images are delivered via HTTPS along with the HTML documents, and the error should go away. The javascript ought not matter. Hope this helps, --Cliff Cliff Woolley Central Systems Software Administrator Washington and Lee University http://www.wlu.edu/~jwoolley/ Work: (540) 463-8089 Pager: (540) 462-2303 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Frames Javascript - insecure?
There are 2 things you can do. 1. Go into the Internet Browser properties (advanced) Remove the check box on "Warn if changing between secure and not secure mode. 2. We also had to change all of our URI's to use full pathnames including the https... This was especially the case with forms and cgi scripts. I hope this helps. Doug Poulin - Original Message - From: Lee Feigenbaum [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 28, 2000 11:25 AM Subject: Re: Frames Javascript - insecure? I did check everything, and everything is being served via HTTPS (everything is specified relative to the main frameset pages, which are all https). In fact, Netscape lists the individual images as being secure, but all of the .html components of the page are listed as 'Status unknown'. Thanks for the suggestion, though, Lee On Fri, 28 Jul 2000, Cliff Woolley wrote: [EMAIL PROTECTED] 07/28/00 12:12PM The outermost frameset is called with a secure URL, and all of the frame src="..." tags use only relative URIs. Nevertheless, when viewed on IE the page gives the warning "this page contains both secure and insecure elements" - it's not an IE specific bug, as Netscape's security summary says the same thing - listing the individual page elements in Netscape shows that it thinks that the html pages, all of which it correctly lists as https://whatever have: You get this if ANY of the elements of the page (eg, images) are delivered via an insecure method (http://, file://, etc). Make sure that *all* images are delivered via HTTPS along with the HTML documents, and the error should go away. The javascript ought not matter. Hope this helps, --Cliff Cliff Woolley Central Systems Software Administrator Washington and Lee University http://www.wlu.edu/~jwoolley/ Work: (540) 463-8089 Pager: (540) 462-2303 __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: : : apache+modssl+... got SEGVs
On Fri, Jul 28, 2000 at 09:03:57AM -0700, David Rees wrote: No one has had good luck when using RPMs to install mod_ssl. I'm afraid that recompiling Apache from scratch is the way to go. What's the problem with the RPMs? I roll them, and if you got a RPM specific porblem, I'll be happy to look at it. Maybe if everyone used the RPMs you rolled there wouldn't be any problems, but it seems that people want to take one RPM from every site, throw them all together, and hope they work. Then they don't because one package wasn't compiled with the right options (like EAPI) There just seems to be too many variables if you want to use RPMs to build Apache/mod_ssl, especially since a lot of people would also like to use RPMs to install other Apache modules I'm sure (php, mod_perl). It also seems that a lot Yeah, mixing Apache RPMs is evil, the dependency facilities in RPM is just not enough to achieve full modularity in apache-mod_ssl There should probably be a FAQ just for doing this... And some things just don't run reliably as a loadable module no matter what you do... mod_perl for example... But I hear that RedHat 6.2 work fairly well, I haven't confirmed, though. of the people that come to the list reporting Apache/mod_ssl crashes are using RPMs. Yeah, and often mixing non-EAPI/EAPI stuff. Too bad the apache group didn't include EAPI, but started to discuss how to do it better, ending up with nothing... /m Why will your project manager kick you for recompiling Apache? You'll only be down for a second or two when you install the newly compiled Apache. Maintenence? It's easier with RPMs... Can't argue with you there. -Dave __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] -- Magnus Stenman mailto:[EMAIL PROTECTED] http://www.hkust.se Get it up, keep it up. Linux -- Viagra for your PC __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
URG: I've replaced the cert, and I broke it!
Ack! Cert has expired so we got a new one from Verisign. I figured I was just replacing the old one (just did the same, successfully, on another server elsewhere) but I must have screwed something up because when I try to start the server up with the new cert i get: 24381:error:0906406D:PEM routines:DEF_CALLBACK:problems getting password:/usr/local/covalent/src/SSLeay/crypto/pem/pem_lib.c:110: 24381:error:0906A068:PEM routines:PEM_do_header:bad password read:/usr/local/covalent/src/SSLeay/crypto/pem/pem_lib.c:387: Now I have picked up this server from another SA that flew the coop(sp) so I am feeling a bit lost here. I have a directory structure that looks like this: /usr/local/ssl | |- bin |- include |- lib |- certs |- private This is from when openssl was just ssleay. Apparently, certificates are in the cert subdir and the private subdir _seems_ to be private keys. And yet, when I look at the old certs in the cert subdir they have both a "RSA Private key" component and a "Certificate" component. However, I seem some private keys that start like this: -BEGIN RSA PRIVATE KEY- and others that begin like this: -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,01339285FAE6F39B What's the diff? So anyway, I generated a CSR, gave that to the person with the credit card who purchased the cert. They gave me the cert and at that point I was unsure of what to do. I'd swear that on that other server all I did was replaced the "Certificate" portion of the file with the new cert and now it is working fine. So I did the same here only I get the error above when I try to start the server. Any ideas? __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: URG: I've replaced the cert, and I broke it!
Mark Drummond wrote: Ack! Cert has expired so we got a new one from Verisign. I figured I was just replacing the old one (just did the same, successfully, on another server elsewhere) but I must have screwed something up because when I try to start the server up with the new cert i get: 24381:error:0906406D:PEM routines:DEF_CALLBACK:problems getting password:/usr/local/covalent/src/SSLeay/crypto/pem/pem_lib.c:110: 24381:error:0906A068:PEM routines:PEM_do_header:bad password read:/usr/local/covalent/src/SSLeay/crypto/pem/pem_lib.c:387: I just realised .. when I start up the server, should it not ask for the passphrase? It doesn't. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: URG: I've replaced the cert, and I broke it!
Mark Drummond wrote: Hello? __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: URG: I've replaced the cert, and I broke it!
Mark Drummond wrote: Ack! Cert has expired so we got a new one from Verisign. I figured I was Forget it. I managed to figure it out myself. I needed to "ssleay rsa pem key" my key file. Um, what exactly does that do? __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
