Our IT department recently updated the certificate of our ADFS server.
Now some of our clients get a certificate dialog, especially Windows and Android devices, if they want to access our web applications and log in via AAD/ADFS.
(Sorry, Chrome blocks screenshots in incognito)
What has our IT department forgotten or disregarded here?
How can I proceed to find the cause?
Reproduce the issue and check if the port number is getting listed as 49443, (this information is not clearly visible in the first screenshot)
If it is 49443, certificate authentication is enabled on ADFS.
Related
I'm having an issue where when trying to connect to my employer's website from my home computers I'm not getting prompted for my smart card credentials whenever I'm using my laptop, however when I'm using my desktop the prompts appear and smart card authentication occurs. Both systems are using Windows 10, and I'm using IE11 and Chrome on both systems. I suspect that there may be some Windows side setting that's blocking the browsers from seeing my smart card on my laptop, but after countless hours of troubleshooting and digging around every possible option online I'm at a standstill here.
Things that I've tried:
Tested smart card reader and card on second computer, no issues, IE/Chrome prompts for certificate and allows login to employer website.
Internet Options > Security > Internet > Custom Level: Don't prompt for client certificate selection when only one certificate exists - set to Disable
Internet Options > Content > Certificates: All smart card certificates are enabled for client authentication
Internet Options > Advanced: SSL 3.0, TLS 1.0/1.1/1.2 enabled
Installed all required PKI certificates required by employer
My smart card certificates do appear under the personal tab, so I know the laptop is seeing them, but for some reason IE and Chrome can't access the certificates (further verified by removing the card, deleting the certificates, reinserting the card and checking that the certificates come back).
I know it's not an issue with my internet connection or my employer's website as my desktop prompts me for my smart card certificate appropriately, so the issue here is limited to just my laptop. At a minimum the website should be pulling up the Windows smart card dialog and prompting me for my card even when it's not inserted, but I can't even get to that point right now.
I finally figured it out after finding a TechNet article on enabling the advanced CryptoAPI 2.0 diagnostics. It turned out that the Kaspersky anti-virus I had installed on my computer was injecting it's own security certificate instead of letting Windows pop up the certificates on my smart card. Uninstalled Kaspersky, everything worked.
I want to use fiddler to monitor api calls made by my browser when it visits some pages.
The technology - Fiddler 4.6x, Chrome 56, Firefox 51, Windows 7 64 bit.
The problem - Fiddler does not work with chrome. When I open any page on chrome, I get the error "Your connection is not private: Attackers might be trying to steal your information from website (for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID". FYI, I easily fixed a similar issue with firefox.
Solutions I tried that failed -
Four hours of google and stack overflow did not give me any solutions.
Convert the fiddler cert to pk 7 ??? format.
Import fiddler cert into chrome. Also, grant the cert all kinds of advanced permissions.
Install the fiddler cert with admin rights on windows, by "running" it.
Run chrome and ignore cert errors.
Regenerating the fiddler cert and restarting fiddler and browsers as given in the official fiddler book.
In 2,3 the cert never appeared in trusted cert store, but appeared in personal and immediate cert store. In 1, nothing even happened. Please tell me how I can make this work. Any links to the basics of all this would help.
I was facing similar issue with Fiddler v4.6 and followed these steps:
Fiddler 4.6.1.5+
Click Tools > Fiddler Options.
Click the HTTPS tab.
Ensure that the text says Certificates generated by CertEnroll engine.
Click Actions > Reset Certificates. This may take a minute.
Accept all prompts
Fiddler 4.6.1.4 and earlier
Click Tools > Fiddler Options.
Click the HTTPS tab
Uncheck the Decrypt HTTPS traffic checkbox
Click the Remove Interception Certificates button. This may take a minute.
Accept all of the prompts that appear (e.g. Do you want to delete these certificates, etc)
(Optional) Click the Fiddler.DefaultCertificateProvider link and verify that the dropdown is set to CertEnroll
Exit and restart Fiddler
Click Tools > Fiddler Options.
Click the HTTPS tab
Re-check the Decrypt HTTPS traffic checkbox
Accept all of the prompts that appear (e.g. Do you want to trust this root certificate)
Reference:
https://textslashplain.com/2015/10/30/reset-fiddlers-https-certificates/
I used these two stack overflow posts -
https://superuser.com/questions/145394/windows-7-will-not-install-a-root-certificate
https://superuser.com/questions/647036/view-install-certificates-for-local-machine-store-on-windows-7
I don't know what is happening. One of these posts worked and I got the fiddler cert into the trusted store. But, fiddler still cannot decrypt many websites https traffic, especially that of google.
After I reinstalled fiddler and did what Abir suggested Fiddler still didn't capture any traffic.
In my case it stopped working because I installed a chrome extension named Tunnel Bear, uninstalling the extension solved it for me.
Firefox has its own certificate store so I assume you just installed the DO_NOT_TRUST... Fiddler root cert there and everything worked. Pretty much you should do the same with Windows certificate store in order for Chrome to work. So make sure you remove all the fiddler certificates you previously generated and regenerate.
if fiddler do not capture chrome traffic, one solution is checking extensions. in my case i use zenmate vpn. when i disable this extension, fiddler capture all traffic in chrome
When i tried to open my site (https://thaimeditationcenter.com/) by Google Chrome on My mac using macOS Sierra Version 10.12 i got an error like this.
Your connection is not private
Attackers might be trying to steal your information from thaimeditationcenter.com
(for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID
Automatically report details of possible security incidents to Google. Privacy policy
But when i open it on Firefox , Safari or Google chrome on my Iphone it seems fine there was no error at all.
How can i fix this?
Thanks!
According to SSLLabs your site is not configured properly:
Chain issues Incomplete
This means that a chain certificates is missing. Some browsers cache chain certificates when visiting other sites and therefore can work around this problem. Other browsers try to download the missing chain certificate. The rest will fail because the trust chain cannot be built.
To fix this you need to add the missing chain certificate to your server configuration. While doing that you should probably also fix all the other problems shown by the SSLLabs report which lead to a bad Grade F for your site.
I need to connect to a web service via HTTPS in my windows phone 8.0 app. It seems that there is no client SSL support from Microsoft about this issue.
I really need to know how to deal with certificates in WP8. What is the correct certificate? Which certificates need to be imported?
Scenario: I have a https endpoint: https://10.1.1.2 and when I connect there from my PC I am being prompted to view and install the certificate of the server. The certificate name "The Root CA" is being saved locally. The same certificate is installed in the mobile device w/o problems. When I open the https://10.1.1.2 from the mobile internet explorer it informs me that the web page is secure and I have to choose between close and continue the page. I am clicking continue and the https://10.1.1.2 transaction takes place. Every time I go to the same URL via the mobile internet explorer there is no warning to the end user regarding security.
According to Microsoft: In most cases, you do not have to do anything
to enable this for your Windows Phone app with the exception of using
an address that begins with the https:// protocol scheme. Windows
Phone then examines the certificate that is returned by the web
service, and if the certificate is from one of the trusted authorities
listed in SSL root certificates for Windows Phone OS 7.1, the Windows
Phone app platform then uses the certificate in conjunction with the
web service to encrypt all further communication, including the
exchange of the authentication credentials as described previously.
Although you can install trusted certificates on the Windows Phone, in
the current release, the Windows Phone app platform does not expose
those certificates’ values to apps. As a result, in the current
release, you cannot implement mutual authentication scenarios –
scenarios in which the client sends its own certificates to the web
service in addition to receiving one -- using certificates installed
in the root store.
So, is this procedure OK? I cannot use one of the certificate authorities that Microsoft
trusts by default. Do I need code?
Self signed certificate cannot be used and it does not automatically fetch data without intervention.
First of all, when testing your SSL connection through mobile IE, it appears from my testing that by pressing continue you are adding an exception to IE, not installing any certificates or getting the exception to apply phone-wide.
Secondly, using self-signed certificates on WP8 appears to be severely limited by the fact that any cert chain that does not use a built-in root CA will generate a failed certificate validation in your code. See the MSDN blog entry at http://blogs.msdn.com/b/davidhardin/archive/2010/12/30/wp7-and-self-signed-ssl-certificates.aspx
Where he states "You can implement your own certificate authority using Microsoft Certificate Services but you’ll still need a certificate from one of the phone’s certificate authorities to chain your certificate authority to."
The only "solution" I've seen posted is to effectively ignore all certificate warnings - which is no solution at all.
I've got a web site that uses SSL Client certificate authorization.
All client certificates are generated using OpenSSL and are self-signed. Everything worked with all web-browsers, but the recommended one was Google Chrome, because it uses same SSL warehouse as IE, so certificate installation was pretty easy (click-click-password-done!).
After last update of Google "Chrome 29.0.1547.57 m", noone can access my web-server, even me.
Google chrome error only! IE and FF working fine.
Error is: ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED.
Same in server error log.
Do you have any suggestions?
The problem is that most part of clients are non familiar with PC's and they got very frightened about that situation. So phone support guys are under the wave of calls.
We are experiencing the same problem. As Sean has reported, it seems that Chrome on Windows XP
negotiates TLSv1.2 even though the operating system does not support SHA-2 (say, SHA-256 or SHA-384)
hash function.
We found that Chrome fails when it receives "client certificate request" following SERVER HELLO.
SERVER HELLO itself negotiates RC4-SHA1 (in our environment) which should succeeds. The problematic
packet seems the "client certificate request" that includes SHA-2 (as well as SHA1) functions for hashes.
Invoking Chrome with "--enable-logging --log-level=0" outputs the following message:
ERROR:nss_ssl_util.cc(193)] ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED: NSS error -12222, OS error -2146893816
This is an Operating system error corresponding "NTE_BAD_ALGID" for CryptSignHash function:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa380280(v=vs.85).aspx
Disabling TLSv1.2 on the server should fix the problem. But I think Chrome should prefer SHA1 on Windows XP.
I'm experiencing the same thing here with Windows7 client systems unable to authenticate with client certificates against some of our systems, but not others. The affected servers are running Apache Tomcat while the unaffected are running IIS7, though I'm hesitant to identify that difference as the culprit.
Anyone else seeing this?
EDIT:
I'm able to eliminate the problem by disabling TLSv1.2 on the server. Is anyone else able to replicate this experience?
I would also be interested to know whether anyone else is seeing this on anything but the Windows platform, as it's the only place it's happening here (same version OSX has no issues).
EDIT2:
Chrome Bug Report here: https://code.google.com/p/chromium/issues/detail?id=278370
EDIT3:
Should be working again in latest Chrome stable. Chrome 30 will have a more robust fix, but 29.x should also work now.
I recently had a similar issue in Chrome on Mac OS. It worked fine with Firefox, but started failing in Chrome and Safari after changing my corporate (AD) credentials -- I guess the issue was a mismatch between system creds and the keychain creds.
The solution for me was a reset of the private key(s) access permissions in the Keychain Access app.
To do the reset:
In Keychain Access app right-click each private key that fails and select "Get Info".
Go to "Access Control" tab and set "Allow all applications to access this item" -- click on that option even if it's already set. Then click Save Changes.
Refresh the website that fails and you should be prompted to enter keychain password -- enter it and select Allow Always.
It is combination of Win XP and Google Chrome 29.0.1547.57 m
On Win 7/8 this problem doesn't occur.
You could install older working version 28.0.1500.95
http://www.filehippo.com/download_google_chrome/15657/
But settings for disabling updating are not so easy.
http://dev.chromium.org/administrators/turning-off-auto-updates
The problem is caused by Chrome running TLSv1.2 on Windows XP.
This can be disabled on the server side but also on the client side.
To run Chrome with a lower version of TLS, start it with the command-line option --ssl-version-max=tls1.1
I had this problem Connecting Chrome with WebSockets to apache throw proxy_wstunnel_module.
My solution was configuring httpd.conf
ProxyPass /wss2/ ws://127.0.0.1:8080/ retry=0 keepalive=On
ProxyPassReverse /wss2/ ws://127.0.0.1:8080/ retry=0
<Location /wss2/>
SSLRequireSSL On
SSLVerifyClient none
SSLVerifyDepth 1
SSLOptions +StdEnvVars +StrictRequire
SSLRenegBufferSize 10486000
</Location>
Chrome WebSockets does not like the parameter SSLVerifyClient optional
I hope this helps.