On Sat, 04 Sep 2010 01:59:17 +0200, fakessh fakessh@fakessh.eu wrote:
i am not running the MS systeme i use CentOS 5.5 and firefox
On Fri, 03 Sep 2010 11:06:49 +0200, "Philipp Gühring" p.guehring@futureware.at wrote:
Hi, You might be running into the Mixed Content problem, but I amnot sure. If that is the problem, then you can read here about possible solutions: http://www.google.com/search?hl=de&client=firefox-a&hs=DnS&rls=o...
Best regards, Philipp -----Original Message----- From: fakessh fakessh@fakessh.eu To: Users users@httpd.apache.org, Openssl users openssl-users@openssl.org Date: Thu, 02 Sep 2010 23:51:28 +0200 Subject: problem https with class 3 cert CACert
hi folks hi all the people hi openssl users hi apache httpdusers t explain my problem i use CentOS 5.5 use httpd.i386 2.2.3-43.el5.centos.3 rpm's centos use mod_ssl.i386 1:2.2.3-43.el5.centos.3 rpms's centos I sometimes against this kind of problem with certificates of type class 3, it was the color in the address bar with the firefox the color in the address bar disappear sometimes and a reload of web page was view again The padlock disappears for the same occasion ... many return and welcome some ideas are welcome ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majordomo@openssl.org
List info: http://lists.roundcube.net/dev/ BT/e81cb6e8
quote auteur This is not an openssl question, nor even an Apache httpd question. It is more appropriately a Firefox question, and the symptoms match the semantics of the "mixed content error".
If any media included on the page (image, audio, video, flash applet, java applet, etc) is served from any insecure URL (http, ftp), the padlock and address-bar color in Firefox go away. This is because the common belief on the browser user-interface is that a page loaded without verifiable evidence that the content requested actually came from where it was expected to come from renders the entire rendering of the content suspect, partly due to the ability to invoke javascript and other scripting from an insecure location which can change the appearance and DOM content of even the parts loaded from secure locations. You can figure out which medium is being loaded from an insecure location by using the Firebug extension.
(Also, if any URL is loaded from an insecure location that redirects to an https location, the padlock and color go away as well. It only stays if the entire page-loading process is across SSL/TLS.)
You can verify this by viewing the page info (on Mac cmd+i; otherwise Tools | Page Info > Security) and looking at the Technical Details pane.
There is no means for OpenSSL or Apache to change the processing path for the display of the user interface -- that is rightly considered the realm of the application, and the application simply takes what is handed to it (the certificate, the evidence that the server provided that it knew how to use the private key counterpart to the public key included in the certificate, and the name of the site it expected) and processes it to verify the certificate chain according to its local rules. Once the local application does this, the local application determines how to display its own user interface. OpenSSL implements the protocol where the certificate is provided to and possession of the private counterpart to the certified public key is evidenced to the client -- called SSLv3 and TLSv1. The things that that protocol can do are the only things that OpenSSL can do, in regards to security concepts, assertions, and evidence.
List info: http://lists.roundcube.net/dev/ BT/aba52c80