I moved my website arvandkala.ir to https recently.
The problem is that some user (specially on mobile) get SSL pravicy Error
the user mobile clock is ok,
don't have a any mixing data on website.
firefox error code:
SEC_ERROR_UNKNOWN_ISSUER
the issuer is Certum and trusted by firefox.
TLDR: it's the chain cert
You need to get the correct chain cert from the CA and configure it in your server.
Normally a CA provides the correct chain cert (or sometimes certs plural) when you buy or obtain your server cert, and also makes all its chain certs (usually several) available on its website, but since I don't know Polish and don't know any customers of your CA certum.pl I can't address these approaches here. Nowadays a common alternative is for the cert itself to specify a way to obtain its parent cert, in the caIssuers attribute in the AuthorityInfoAccess extension. This can be seen with many tools, including (at least) desktop browsers, OpenSSL (x509 -noout -text -in $file), and Java keytool (-printcert -v -file $file), and your cert does have it, pointing to http://repository.certum.pl/dvcasha2.cer . Fetching that URL with a tool that does not interpret the content (i.e. not a browser, but things like curl wget perl python or javascript) does yield the correct cert, in DER format.
Configuring your server varies hugely depending on the server, which you didn't identify. Your server identifies in a response as Server: Apache/2.4.7 (Ubuntu) but this could be falsified because some people consider that a good way to confuse attackers (not very) or mistaken because some other terminator is in front. If true, although there are other possibilities I'll assume the common default mod_ssl. The documentation for Apache 2.4 mod_ssl is located on the Apache website under docs / 2.4 / modules / mod_ssl . As this page tells you for 2.4.8 up you can include the PEM-format chain cert with the server cert in the file specified by SSLCertificateFile, but below that you must put them both in a file specified by SSLCertificateChainFile instead. This config (certificate including chain, plus privatekey) can be per virtualhost, or if you don't need them to be different it can be global. On Ubuntu the usual practice (though not mandatory) is to put each virtualhost config in a separate file under /etc/apache2/sites-available and link it under (same)/sites-enabled.
Since the certficate obtained from the CA was in DER format you must first convert it to PEM format. This can be done directly by OpenSSL with openssl x509 -inform der -in $derfile -out $pemfile or by numerous other programs that can import DER format and then write out PEM format (including at least Windows, Firefox/NSS, and Java).
Related
My understanding of HTTPS is that the encryption and decryption is done in the process, and any data that passes through the OS is encrypted.
Most HTTPS MITM tools work by editing the HTTPS client to send requests via a proxy, and/or accept invalid SSL certificates.
Given:
Program A is a binary program that contains an HTTPS client (that does not use a proxy and only accepts valid SSL certs).
Program A cannot be modified.
The OS can be modified, instrumented etc.
Would this mean the responses processed by the program have definitely come from the server and are not modified?
Does HTTPS have protection for replay attacks (sending the same encrypted response that was recorded earlier)?
Given:
Program A is a binary program that contains an HTTPS client (that does not use a proxy and only accepts valid SSL certs).
Program A cannot be modified.
The OS can be modified, instrumented etc.
The question is, what are valid SSL certificates, how does the browser know? Firefox has its own certificate store, but Google Chrome uses the OS certificate store (they are creating thier own certificate store). Firefox however, does not load the OS certificate store by default. So your reasoning holds up for some browsers.
Being able to edit the trusted certificates on browsers is used, quite extensively, on intranet sites by corporations, so they don't have to get their certificates signed by a trusted third party.
As for your last question, https://security.stackexchange.com/questions/20105/are-ssl-encrypted-requests-vulnerable-to-replay-attacks explains this very well.
Sources:
https://www.zdnet.com/article/chrome-will-soon-have-its-own-dedicated-certificate-root-store/
https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox
I've been trying to setup client certificate authentication for almost three days now but to no avail.
I've signed up for a free domain at heliohost and have installed a free ssl certificate issued by Let's encrypt.
My plan is to have self signed certificates and check them against the database later(for user authentication) therefore I set my SSLVerifyClient to optional_no_ca in the htaccess file. I installed several self signed certificates generated by openssl but no matter which browser I try(Chrome, Firefox or IE) I get no prompts to choose a certificate except when i tried to access it on my phone via Chrome, in this case it offers to install a certificate since I don't have any on the phone.
This is the content of my .htaccess file:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
SSLOptions +StdEnvVars
SSLRequireSSL
SSLVerifyDepth 1
SSLVerifyClient optional_no_ca
I would really appreciate any feedback pertaining the issue, this is my first time trying to implement this and I'm not sure weather the issue is with my setup or chrome.
also I'm using chrome 59
Kriss
You have omitted the part of the ssl certificate authorities configuration. it is needed to configure the CA certificate that signs your client certificates ( see this
SSLCACertificateFile "conf/ssl.crt/ca.crt"
The server is not sending the root CA, then since you have set SSLVerifyClient to optional_no_ca, the browser automatically performs the connection because it can not find any suitable certificate (see below TLS1.2 note)
Since you have set optional_no_ca in your server, it accepts the connection even if no certificate is presented. It you set require you will find that the connection fails with Chrome.
SSLCACertificateFile is not configurable in .htaccess. Since you can not customize chrome, i am afraid you need to configure this parameter to force certificate prompt
When the certificate list is empty, the behavior between browsers may vary because the TLS specification allows it
See TLS1.2 RFC
7.4.4. Certificate Request
certificate_authorities
A list of the distinguished names [X501] of acceptable
certificate_authorities, represented in DER-encoded format. These
distinguished names may specify a desired distinguished name for a
root CA or for a subordinate CA; thus, this message can be used to
describe known roots as well as a desired authorization space. If
the certificate_authorities list is empty, then the client MAY
send any certificate of the appropriate ClientCertificateType,
unless there is some external arrangement to the contrary.
7.4.6. Client Certificate
[...]
If the client does not send any certificates, the
server MAY at its discretion either continue the handshake without
client authentication, or respond with a fatal handshake_failure
alert.
The issue was due to chrome, I have unfortunately not been able to pinpoint it but managed to get it working and prompting me for the certificate on firefox.
Thank you for the answers.
I use the following options passed to https.createServer,
options =
ca: splitca fs.readFileSync sslpaths.capath, encoding:'utf8'
key: fs.readFileSync sslpaths.keypath, encoding:'utf8'
cert: fs.readFileSync sslpaths.certpath
Where splitca just to splits the two pem blocks of the CA crt bundle file. However sometime Chrome does not like this and when I load my domain it says that the certificate cannot be trusted. Then sometimes it works just fine and shows two Comodo CA nodes coming from the addTrust root, followed by my servers certificate. When I use openssl s_client -connect mydomain.com:443 -showcerts I get the error 'unable to get local issuer certificate'. When I remove the ca parameter completely then Chrome will still sometimes work, but openssl still does not have the two CA pem blocks in the certificate chain. I am guessing that Chrome is doing its own lookup of the CA and caching the certs?
I also tried prepending the CA crt file to in front of my server crt file and before upgrading my nodejs (v0.12) I would get some kind of handshake sslv3 failure from openssl. Now when I try with nodejs v5.0, I get error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch being thrown from nodejs. Any help would be appreciated.
I have a NodeJS server on Amazon EC2.
I'm trying to set up SSL using certificates from "COMODO RSA Domain Validation Secure Server CA".
I got it working for all browsers except Firefox. Is this a common issure?
Please check that the server provides all intermediate certificates (trust chain). A common issue is to forget the intermediate certificates and then get errors on some browsers an no errors on others. This is caused by the browsers caching the intermediate certificates, e.g. if you've visited a site using the same intermediate certificates before, the browser will dutifully use these cached intermediates if the server forgot to server them. But, if the browser never visited such site before the intermediates are not cached and thus the verification will fail.
A good test is to use openssl s_client -connect your.https.server:443 and look at the chain of certificates it provides. Also, https://www.ssllabs.com/ssltest/analyze.html will point out such problems.
I created the server.key and server.csr files using openssl req -nodes -newkey rsa:2048 -keyout server.key -out server.csr. I created a SSL certificate with startssl.com which gave me a certificate file. Then in my node.js application I read the key and certificate files:
var app = module.exports = express.createServer({
key: fs.readFileSync('server.key'),
cert: fs.readFileSync('server.cert')
});
But, now I get an empty response from my application, a "No data received" message. What could be causing this? I'm very new to SSL and how it all works, so any help with this is very much appreciated.
More info: I generated the two files, key and csr files, on my VPS server (production server), and now I'm trying to get them to work on my localhost (firstly, before I commit my code to production; I have to test that it works before making a git commit). So, it could be due to the fact that my localhost (development environment) is on a different domain from my VPS server (production environment). Could this be the case? If so, how can I make it to where the localhost and production environment use the same certificate?
Or, would you suggest I create another certificate for my development environment? The only problem I see with that, is that I wouldn't have a domain for my dev environment because it's done locally. I'd rather much use the same certificate (even if that means a broken lock icon or something on localhost) for the sake of simplicity.
I know this is an old question, but I encountered the same thing today. I would get the same result back from express (ERR_EMPTY_RESPONSE).
The fix? Be sure to specify https, and not http, in your test browser (e.g., https://localhost:8443).
If you previously used middleware to forward all http requests to https you wouldn't have seen this problem before. Also, expect your browser to complain about the certificate, but proceed through anyway (in chrome this takes several clicks).
You can troubleshoot errors by connecting to your application with curl --insecure --verbose. Generally you shouldn't use an SSL certificate on more than one host. You can make a self-signed one to test locally and use the startssl one in production. But in any case, the CN in the cert needs to match the hostname used to connect to the site to avoid annoying browser warnings. You can always make up a domain name for your machine like sam.local and put that in your /etc/hosts file and use that in your self-signed certificate as well as your browser address bar.