Landfill of Wisdom

My bank uses client SSL certificates + a single-password token for authentication. Unfortunately, the latest Firefox gives me this error: Secure Connection Failed An error occurred during a connection to secure.example.com. Renegotiation is not allowed on this SSL socket. (Error code: ssl_error_renegotiation_not_allowed) The page you are trying to view can not be shown because the authenticity of the received data could not be verified. Please contact the web site owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site. A workaround, which I do not recommend, as pointed out here , is to set security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref from about:config to true. A more correct solution would be to read up on the decision to disable the feature, and then just add your server to the security.ssl.renego_unrestricted_hosts configuration value instead.

Just to summarize why Firefox does not trust the https://www.clevery.co.jp/ online shop. Apparently the server at https://www.clevery.co.jp/ only sends its own certificate when I open their page. What most sites usually do is that they send not only their own certificate, but also the certificate of their issuer, and the certificate of that issuer and so on up to the root certificate (excluding the last one). What is happening with the clevery server is that its certificate contains an extension that points to the location of the parent certificate. As given by OpenSSL Authority Information Access: OCSP - URI:http://ocsp.verisign.com CA Issuers - URI:http://SVR1024Secure-aia.verisign.com/SVR1024Secure2007-aia.cer So, apparently Firefox doesn't follow that path and that seems to be a recognized standard. A quick Google found this article by someone who ran into the same problem and who has already checked the status of that extension. I'll have to look more into it myself, but ...

Logwatch was good enough to show me that I had my logs filled with messages like these... repeating themselves over and over ad infinitum:

I am running netqmail patched for with TLS support under sslserver from the ucspi-ssl package. However, every time a connection is closed the sslserver process segfaults. On the Opteron it also causes messages like sslserver[13106] general protection rip:2ab6c23cf687 rsp:7fffe89e9308 error:0 to appear in my system log. Currently tracing the problem, but it seems that the process dedicated to handling the encryption assumes that it has to start an encrypted connection even though it has not been requested to do so. I'll have to dig around a bit more. Update: I also have a very trivial patch that fixes the issue. I've been running with it for over an year now and there have been no issues so it should be safe. Here is the file: ucspi-ssl-070-fixsegfault.patch

Here is a short summary of how I am managing my SSL certificates Edit /etc/ssl/openssl.cnf and add a section for each separate certificate authority, e.g. CA_servers CA_clients, CA_vpn Use a safe umask: umask 077 Generate a private key an unencrypted key (no password needed) openssl genrsa -out key.pem 2048 an encrypted key (with a password) openssl genrsa -aes256 -out key.pem 2048 Create a certificate request: openssl req -new -key key.pem -out req.pem Sign the certificate: openssl ca -name CA_vpn -in req.pem -out cert.pem Optionally add specific extensions to the signed certificate: Prepare a section in /etc/ssl/openssl.cnf like this: [ext_server] nsCertType = server, client Modify the signing command like this: openssl ca -name CA_vpn -in req.pem -out cert.pem -extensions ext_server