I am witnessing a weird issue with regards to mutual authentication.
I have setup mutual authentication on BigIP loadbalancer to accept 2 different CAs.
This means that we only accept certificates that has been issued by those 2 CAs.
I have tried providing those certificates to LB using OpenSSL and it works fine by this i mean i have 2 certificate, Using IE it works fine as well, FireFox it works fine as well. but when i use chrome, browser asks for certificate but it doesnt send the certificate to the LB, as it has been observed in wiresharks (Picture to follow)
I have access to both certificates, so i extacted the certs and key and used
openssl s_client -connect Host:port -cert "cert.pem" -key "key.pem"
It works fine, and i can see connection is ok.
Using same certificates in IE, it works as well.
Postman works as well.
FireFox Works as well.
Chrome however it shows certificate length as 0
And as you can see same certificate is used by OpenSSL and it is sending.
Any idea what might be the problem?
Update :
I started chrome with debug and saw this, it seems chrome cannot parse my key or cert.
[14836:18604:0927/172254.921:ERROR:ssl_platform_key_util.cc(70)] Could not parse public key.
[17536:16164:0927/172255.100:ERROR:ssl_client_socket_impl.cc(941)] handshake failed; returned -1, SSL error code 1, net_error -117
In my case, there was a problem with the ASN.1 encoding of the Algorithm Parameters in the certificate. The encoding missed a NULL value. If you upload your certificate, we can double-check.
Related
Issue: users can't log into mobile app due to "unable to contact server"
debugging message: "TypeError: Network request failed"
Attempted fixes: restarted server, verified that db is running and nothing has changed, restarted VM that server is running on, I checked the api using postman. When I ran a simple POST request I got the following message:
There was an error connecting to
https://app.something.com/api/Accounts/5076/sometest?filter%5Bwhere%5D%xxxxx%5D=null&access_token=mwVfUBNxxxxxxx5x4A4Y5DktKnTZXeL6CB34MoP.
One of the suggestions I was given was:
Self-signed SSL certificates are being blocked: Fix this by turning
off 'SSL certificate verification' in Settings > General
As soon as I followed this step, I was able to make the POST request and everything seemed to work fine. I'm completely new to this type of error. Allso, I did not set up this app/db/certificates. So, other than unblocking self-signed SSL certificates(which seems like a really bad idea), I'm not sure how to proceed. What are my options?
here's what the result of examining the certificate:
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
verify return:0 poll
errornotBefore=Jan 28 11:54:38 2019 GMT
notAfter=Apr 28 11:54:38 2019 GMT
Either, purchase a signed certificate from a CA if you plan to expose this to the public.
Or the free option is to use Let's Encrypt, with this service, you are issues free certificates, however they expire in a relatively short period of time; most of the time however you can run an agent which will automatically rotate the certificates before they expire.
The third option is to install the CA certificate that was used to self sign this, into to your browser. i.e., like a large company might do.
edit
Seems like it might instead be an expired certificate? Check when it expires with this:
openssl s_client -showcerts -servername www.stackoverflow.com -connect www.stackoverflow.com:443 </dev/null | openssl x509 -noout -dates
change both instances of stackoverflow you your domain
First I want to point out that this works fine with Internet Exporer 11. But for some reason I just can't get FireFox to play nice!
So I already added my own rootCA security certificate and under Internet explorer it works fine and my website with self-signed cert is trusted.
But on Firefox v61.0.1 and also v65.0 even though my root certificate is already added, and in addition security.enterprise_roots.enabled is set to true (in about:config), I still get the "your connection is not secure" message and I have to add a security exception just to view my site.
In the area with the message and button to add exception, Firefox says:
"xx.xxx.xx.x uses an invalid security certificate. The certificate is only valid for xx.xxx.xx.x. Error code: SSL_ERROR_BAD_CERT_DOMAIN"
Now the xx.xxx.xx.x is an internet reachable IP address and both instances in the above line have exactly the SAME IP address, I've used IP for the CN field.
clicking on SSL_ERROR_BAD_CERT_DOMAIN shows:
"Unable to communicate securely with peer: requested domain name does not match the server’s certificate. HTTP Strict Transport Security: false HTTP Public Key Pinning: false Certificate chain: -----BEGIN CERTIFICATE----- ......."
Anyway, I am guessing that in its current configuration, Mozilla FireFox is CONFUSED that the site has an invalid certificate when in fact it is valid and the reason for its confusion is perhaps it expects a domain-NAME not IP address.
If so, is there a way I can tell Firefox to honor IP Address based ssl certs?
Again, current config is working perfectly fine with Internet Explorer for me.
As you know many tools like built-in IDE svn and other source control clients really do not like it when there's something to complain about in an ssl-cert.
That's the reason I went through trouble of creating and loading own Root CA Authority in windows. And no please do not recommend letsencrypt, needs renew often and I don't have incoming OPEN ports which it seems to require to renew.
thx!
Hooray! Success :) I went by my what I thought was confusion over IP vs name and discovered that my extfile under the [alt_names] section I had used DNS.1 = xx.xxx.xx.x
So I simply edited my extfile and changed DNS.1 = ... to now be IP.1 = xx.xxx.xx.x
Then I simply recreated my webserver's cert. For anyone wondering, here's actual command:
openssl x509 -req -in mywebserver.csr -CA myrootCA.pem -CAkey myrootCA.key -CAcreateserial -out ./certs/mynginxwebserverIP.crt -days 2555 -sha256 -extfile myextfile.cnf
That overwrote my current .crt file and all I needed to do was nginx -s reload and bingo!
Well hope that helps someone cuz it was driving me crazy!
Now it works just fine in Firefox and I get that comforting nice green lock :)
And internet explorer didn't know/care about the difference, worked both ways :D
I'm trying to set up client certificate authentication. I was able to generate a CA-, server- and client-certificate. As long as I use Fiddler everything works as expected. However, as soon as I start using a browser it doesn't work anymore (HTTP Error 403.7 - Forbidden).
Of course I imported the client certificate in the Personal store and I made sure Client Certificate Negotiation is enabled.
I also tried openssl s_client -connect 127.0.0.1:443 -state -debug but I couldn't really make sense of the result... The only thing what's weird is that my CA doesn't show up in the Acceptable client certificate CA names section.
Anything else I could try?
Update:
I think it doesn't matter but my server certificate is set up for 127.0.0.1. Therefore I'm using https://127.0.0.1/... in my browsers.
Update2:
Using Wireshark I noticed that my servers' response depends on the client:
Fiddler (OK):
Client Hello
Server Hello, Certificate, Server Hello Done
Browser (Not OK):
Client Hello
Server Hello, Change Cipher Spec, Encrypted Handshake Message
Update3:
After enabling clientcertnegotiation the server response is different but still doesn't work:
Server Hello, Certificate
Certificate Request
Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
My self-signed CA doesn't seem to be in the Distinguished Names list...
Update4:
SSL Settings: Checked Require SSL and Client certificates set as Required. Client cert shows up in Personal and the intended purpose is Client Authentication.
I finally found the issue and a workaround:
As mentioned in Update3, Distinguished Names doesn't contain my CA. This is because Distinguished Names has a limit of 2^14 bytes (16384 bytes). Because I do have a lot of CA installed on my machine my CA simply didn't make it in. The TLS standard would allow to send multiple messages but unfortunately Windows doesn't support this!
As mentioned here you have a few possibilities. The simplest one is this:
At your server add a DWORD (not QWORD!) value called SendTrustedIssuerList in your registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL and set it to 0. This will prevent your server from sending a list at all, letting the client choose from any installed client certificate.
Unfortunately I couldn't see any traces in the Event Viewer (as reported elsewhere). Therefore the issue wasn't easy to spot (I had to use Wireshark in order to check Distinguished Names).
Use the Accept option instead of the Require option of the "Client certificates" feature.
In IIS Manager, locate the Web application for which you want to change the SSL setting.
In Features View, double-click SSL Settings.
On the SSL Settings page, select the Accept option under Client certificates.
In the Actions pane, click Apply.
More info here
Client certificate should be imported in CurrentUser\My store with private key (i.e. p12 or pfx file usually).
CA certificate should be in LocalMachine\Root store so that IIS trusts all certificates issued by the CA and the CA is trusted for every user on the computer.
CRL issued by the CA should be either available through URL (specified in every end entity certificate that CA issued) or imported in LocalMachine\My store.
NOTE: openssl doesn't use windows certificate store so this will have no efect on openssl s_client -connect 127.0.0.1:443 -state
We are developing an application using tomcat and jersey.
Within this webapplication we need to connect to a https Website with a valid, not expired certificate.
If I do connect to this website locally via my chrome browser, everything works fine!
Unfortunately the tomcat server with our webapp throws an exception. We are using the Apache HttpClient (4.0) to connect to the https site:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:371)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:126)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
The server certificate is absolutely valid and from thawte.
Three different online tools validated the certificate successfully.
Openssl has an issue, too and showing me three certificates but throwing a simple error:
Verify return code: 20 (unable to get local issuer certificate)
The problem with openssl seems to be that it uses the wrong path /usr/lib/sslinstead of /etc/ssl/certs. If I use the CApath argument pointing to the proper path, openssl works fine so may this be an issue with the httpClient?
So our code for the default client is quite simple:
client = new DefaultHttpClient();
response = client.execute(url); //this throws the exception
EntityUtils.consume(response.getEntity());
It's not an option to allow any certificates by implementing a custom TrustedManager!
Futher I read, that some CA's are not part of the JDK/JRE and so it's certificates should be imported manually into the keystore or use a custom one, but thawte is a well known CA and shouldn't it work on default?
EDIT
I did set the javax.debug properties in catalina.sh so that I have further information about the problem:
http-bio-8080-exec-1, handling exception: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path validation failed:
java.security.cert.CertPathValidatorException: basic constraints check failed:
pathLenConstraint violated - this cert must be the last cert in the certification path
I would appreciate any help!
Thanks in advance!
Okay, I got it working!
Although thawte is a well known CA it seems that Java SSL did have some problems with it.
After downloading the ssl Certificate via openssl:
echo |\
openssl s_client -connect ${REMHOST}:${REMPORT} 2>&1 |\
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
and saving it into an pem file, I did the manual import into the java keystore:
keytool -import -alias myAlias -file theCert.pem -keystore lib/security/cacerts
I have no idea why java ssl was not able to validate the thawte certificate properly.
Listing the keystore showed me, that there are 7 thawte trusted certificates in the standard keystore but bizarrely it did not work until I manually imported the pem file
I am trying to understand your setup. You have a SSL certificate (issued by Thwate), installed in tomcat and you can access your site just fine over SSL using say IE or Firefox or Chrome.
But when you try to access it using HttpClient, you receive the above error ?
Is that correct ?
The error clearly indicates that your client does not trust the CA. But if the cert is signed by Thwate (and is installed correctly and is acessible via IE/Firefox etc), then it should work fine.
I bought a SSL Cert which should work with iE 5+, but it doesn`t. All other browsers i tested work perfectly - no errors - just the site I want to display. But IE8 and smaller versions show an Error on the https...(they need to accept the ssl cert) site and destroy the layout on http version of the site (no https links included).
Non SSL
minol-fb.de/facebook-suche/
SSL
minol-fb.de/facebook-suche/
Ok it seems that browser < IE8 still use the self signed certificate..
You must have configured multiple certificates using Server Name Indication without knowing it.
If you use this, you get a self-signed certificate:
openssl s_client -showcerts -connect www.minol-fb.de:443
If you use this (with the server name), you get the correct certificate:
openssl s_client -showcerts -connect www.minol-fb.de:443 -servername www.minol-fb.de
You probably get a different behaviour with older versions of IE because you're testing them on XP. No version of IE supports SNI on Windows XP unfortunately. Other browsers (with sufficiently recent versions) do, at least independently on the OS version they run on.
If you don't need that other host, you can probably remove that configuration, so as not to have to rely on SNI at all.
Something odd is going on; if you use the link below you will see that the server is not returning the server cert and intermediate cert, but a single self signed Parallels Plesk Panel CA cert.
http://certlogik.com/ssl-checker/www.minol-fb.de
Using the openssl command below, I get the same Plesk certificate returned:
openssl s_client -showcerts -connect www.minol-fb.de:443
Perhaps this may help:
http://knowledgelayer.softlayer.com/questions/457/Installing+a+SSL+Certificate+in+Plesk+9
UPDATE:
Looks like you've sorted out the config; using the above tool I can see the correct certs are now being returned.
I ran into a similar situation where the cert was working OK on all browsers except for IE (of course!). This is on Apache and the SSL cert had been issued by RapidSSL. Turned out in my case, that I had virtual host file default-ssl active, so somehow IE was picking up on that on the default self-signed cert instead of the rapidSSL cert referred to in my site virtual host.
Deactivated ssl-default, reloaded apache and that did it.