Finally I was able to reproduce the problem. I don't know why FF10 worked locally on the ELOG host last weekend, maybe I shouldn't have worked on it during a night shift. I can now confirm that ELOG has problems with firefox 10.0.1.

For those who need a quick workaround: you can set-up apache to access elog via a reverse proxy (like I do and like Stefan does for the ELOG forum does). That 'll work fine with new browsers like FF10.0.1 (at least for apache 2.2) ;-)

Some guidance how to set it up can be found here: https://midas.psi.ch/elogs/Contributions/11

A shorter (but may be incomplete) summary:

• add in httpd.conf
  • Listen 443
    LoadModule proxy_module modules/mod_proxy.so
  • ServerName <fully-qualified-host-name>
  •  
• add in ssl.conf
  • <VirtualHost _default_:443>

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn
SSLEngine on
SSLProxyEngine on
ProxyPreserveHost On
<Location />
    ProxyPass         https://<fully-qualified-host-name>:444/
    ProxyPassReverse  https://<fully-qualified-host-name>:444/
    SSLRequireSSL
</Location>
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLProxyCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile "<cert-file>"
SSLCertificateKeyFile "<cert-key-file>"
</VirtualHost> 

• And in the ELOG configuration [global] section
  •  port = 444
  • URL = https://<fully-qualified-host-name>                 

Cheers

Andreas

Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Detect language Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish ⇄ Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish

Detect language » English

 

Andreas Luedeke wrote:

John Doroshenko wrote: Olaf Kasten wrote:  Hi there, I have a connection problem with an actual elog installation. Many Browsers like as Chrome, Firefox and IE don't  connect to the elog server with ssl = 1 in elogd.cfg.  I tested with Firefox 3.6 and IE 7 installations and there are no problems. I guess it's a bug. Does someone have a suggestion to solve that problem? Thx. Olaf  Hi! This just started happening here also.  Some users can't get on to a SSL=1 config'd elog using either IE or firefox 10 (win7 or linux) or chrome.  SAFARI works.  Occurs in 2.8.0 and a newly built (even after ssl yum updates) 2.9.0 version on SL5.5 system.  Seems to accept self signed cert then nothing.. (connection reset message).   Tried an stunnel from one port to port running elog with SSL=0.  Same behavior.  Doesn't work on some browsers.  Any clues? Thanks, -John Hi everyone, it appears that many people have this problem. I believe this is simply a problem of your firewall settings. There are two simple checks you can do to test if I'm right or wrong: Run your logbook on the standard port 443 and retry. If the special port has been opened on the firewall, it has been likely only opened for specific clients like firefox 3.6, IE 7, etc. If you use a different client (FF 10, IE 9) the port can be blocked. Or just run the browser that does not work on the ELOG server. If it works to access ELOG via localhost, then you know for sure that it is the firewall. I've actually tested it here at my institute: I've downloaded firefox 10 and could access ELOG on port 443 but couldn't access it on port 444, unless I've started FF10 on the ELOG host. To John, Olaf and Christian: If you need to be able to use a special port and a certain set of browsers then just contact your computing division or whoever maintains your firewalls.   I hope this settles the matter. Cheers Andreas   Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Detect language Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish ⇄ Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Detect language » English   PS: I've solved this with the help of google  : have a look at http://forums.mozillazine.org/viewtopic.php?p=2295421#2295421 about firewalls

 Hi,

Thanks for the reply. 

The elog server is running SL5.5 (updates applied).  As you suggested, I ran firefox 3.6.26 on the elog server via https://localhost:port and it worked fine.   Downloaded firefox 10.0.1 and retried

on elog server and get error again:  The connection was Reset; The connection to the server was reset while the page was loading.

-John

Yes, there is a new feature called record splitting which causes the browser to send the "G" of the "GET ..." in a dedicated TCP package. This started in FF10, Chrome 17, and it will come in others as well. It only affects direct SSL connections (SSL=1). I fixed the bug in SVN revision #2435. Please update also MXML to revision #73. Let's hope that surprises like that will not happen too often.

- Stefan
 

Yes, there is a new feature called record splitting which causes the browser to send the "G" of the "GET ..." in a dedicated TCP package. This started in FF10, Chrome 17, and it will come in others as well. It only affects direct SSL connections (SSL=1). I fixed the bug in SVN revision #2435. Please update also MXML to revision #73. Let's hope that surprises like that will not happen too often.

- Stefan
 

We obtained a certificate from let's encrypt in order to replace the self signed certificate provided with elog. We copied the new certificates replacing the older server.crt

The problem is that when restarted elog raises an error related to the fact it is looking for server.crt and it doesn't find it anymore.

I searched in elog config file in order to find a way to indicate the new certificate but I didn't find how to manage this issue.

Any suggestion?

Hi Giuseppe,

The new certificate files should be copy under ssl folder (/usr/local/elog/ssl or /usr/share/elog/ssl by example, closed to templates and script directories) in place of the embedded (autosigned) certificate files enclosed with ELOG source.

It seems that there is no parameter to set a custom path.

SSL = <0 | 1>
Turn on Secure Socket Layer transport. If SSL is on, one can connect via https://... to the elogd daemon. If the URL = directive is used, make sure to use https://... instead of http://... there. The ELOG distribution contains a simple self-signed certificate in the ssl subdirectory. One can replace this certificate and key with a real ceritficate to avoid browser pop-up windows warning about the self-signed certificate. The default for this option is 0.

Hi Laurent,

thanks very much! Probably I've copied the certificate in the wrong directory. I'll try ASAP