when I use chrome 107(64 bit) and chrome 107(32 bit) in windows10 64bit computer(same computer, only chrome brower bit change), PKI login are not same.
when i use chrome 107(64 bit), Client Certificate Not Sent To Server:
but when i change to chrome 107(32 bit), Client Certificate is OK!!!:
that why???
can anyone help me.
I have try in:
same computer
only change chrome brower 64 to 32 bit
also test multi chrome version, example: 107、84、103
test much times and reboot computer, then have same result
Related
I am running automated tests under Linux (CentOS) in headless mode.
I got a site where I need to provide an SSL certificate for HTTP SSL client authentication. The file is .p12 format, I installed it the same way on two machines (VM running CentOS with UI, the other is a normal headless server, again running CentOS).
Using pk12util I installed the certificate in the browser store, confirmed successful installation, then added the policy for Chrome to use the certificate automatically for the website in question.
Now the fun starts. In the VM where I have UI, I run the browser in headful mode, everything works perfectly. However, when on either machine I run the browser in headless mode, I need it to run headless for the server, I get the following errors in the driver log:
[DEBUG]: DevTools WebSocket Response: Page.navigate (id=18) 5944A53229353F1849E7D2D15FA4A11C {
"errorText": "net::ERR_SSL_PROTOCOL_ERROR",
"frameId": "5944A53229353F1849E7D2D15FA4A11C",
"loaderId": "4F3404B14470DD65090915C651B3D3EC"
}
...
[cf5020dd474256cce9c41538b1ffa0c2] RESPONSE Navigate ERROR unknown error: net::ERR_SSL_PROTOCOL_ERROR
While running in headless mode, I switched on the debug port, 9222, and I see in the Network tab that the request failed with the error "Failed to load response data: No resource with given identifier found".
Before installing the SSL certificate I had the same error in headful mode, but when I installed the certificate and added the policy, it went away, which makes me think that for whatever reason, the headless Chrome can't find the certificate.
Did I miss something? Can we provide SSL client certificates in headless mode? Does anybody have any suggestions?
Thanks!
PS: In headless mode the browser is started with the usual flags: acceptInsecureCerts=true, --ignore-certificate-errors, --ignore-urlfetcher-cert-requests.
I am running under CentOS 7.9, Chrome v.99
Well I actually found the answer.
Unfortunately, it does not work!!!
It is all explained in the following issue.
Issue 1310715: Headless Chrome not using installed client (authentication) certificates from the store.
This issue shows the steps to reproduce.
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.82 Safari/537.36
Steps to reproduce the problem:
Have a website behind a webserver that has browser client authentication with an SSL certificate.
Install the certificate in the certificate store of Chrome under $HOME/pki/nssdb folder. My certificate was in pk12 format, so I used pk12util to install it.
The installation must exit with: 'pk12util: PKCS12 IMPORT SUCCESSFUL' message.
Add a policy to your website under /etc/opt/chrome/policies/managed, so that Chrome provides the certificate automatically to the site's webserver.
Open the website.
What is the expected behavior? When the browser is started in headless or headful mode, the browser should provide the certificate to the webserver and proceed further.
What went wrong? Only in headful mode does the browser provide the certificate to the webserver. Headless mode does not. There's this error in the logs:
The issue response states the following:
Headless Chrome doesn't currently implement client certs. Switching this to a feature request that the headless folks can triage. Mechanically, client certs are come out of //content via CreateClientCertStore and SelectClientCertificate. Headless doesn't have a way to show UI, so it always continues without a client certificate.
https://bugs.chromium.org/p/chromium/issues/detail?id=1310715&q=component%3AInternals%3EHeadless&can=2
When connecting HoloLens via USB to my computer, the device portal is still not available after setting it up as explained in the install tools page.
All I get in the browser 127.0.0.1:10080 is the generic "unable to connect" page.
Is there any way to know what is failing? What could I check? Any tip will be appreciated!
EDIT: browsers used: Edge, Firefox and Chrome.
EDIT2: Hololens development mode is on.
Connecting over USB requires the PC be running IPoverUSB, which is installed with the Windows 10 SDK. You can verify that it's running by checking the Services tab of Task Manager for IpOverUsbSvc.
FYI, another resolution to this issue may be the USB port you are using.
I initially was using a USB 3 port (which I've used to flash my HoloLens many times) and had the same issues.
On a whim, I switched to an older USB2 port and it's working perfectly now. SO try different USB ports if you are having this issue.
Having an issue with my SSL certificate. Often it seems to work fine, but sometimes the user's browser throws up a warning that it is not trusted.
I know very little about SSL certificates, but here is some information that may or may not be relevant:
URL: demo.EnterpriseJazz.com
It is a wild card certificate because
the application uses subdomains (one subdomain per registered organization Example: BobsLawnCare.EnterpriseJazz.com)
The certificate was cheap for a wild card certificate, I paid around $50 for it if I remember correctly. I believe I got it from a cheap re-seller.
The server is located in my house on a Verizon FIOS business internet connection. It is not in a data center.
Seems to work fine with:
Safari on my new Macbook Pro
Chrome on my new Macbook Pro
Firefox on my windows machine
Microsoft Edge on my windows machine
Internet Explorer on my windows machine
Opera on my windows machine
Firefox on my Linux machine (CentOS)
Not trusted with:
Chrome on my iPhone 6s
Safari on my iPhone 6s (screen shots below)
Have a look at the SSLLabs report for this site. Apart from a shockingly insecure setup you will notice:
This server's certificate chain is incomplete.
This means that the client has not enough information to build the trust path to the root certificate and thus can not accept the certificate as trusted.
However a desktop browser will attempt to work around such setup problems by trying to fill in the missing chain certificates, i.e. downloading these from the web or using cached certificates from earlier connections to other clients. But apart from the desktop browsers most other clients will not do it and thus fail.
I had the exact same issue.
After futzing with every nook and cranny of my SSL and http setups, I finally realized "How silly I was to not check the URL first!"
My browser had been connecting to the regular non-trusted site (http://example.com) and I had blindly assumed that the broken lock icon meant something was wrong with my cert installation. Duh!
Modern browsers hiding the actual protocol letters behind a pretty icon or user-friendly message that conflates two issues into one - that didn't help.
My suggestion would be to first make sure you're hitting the https version of your site. If not, your first step to the solution is to create an automatic redirect of all http to https.
I hope getting to this post first helps at least 1% of those who had this problem. I'm in that 1%
I'm using Selenium remote web driver for gui testing. The server is on Linux, the browser is on Windows. Everything works fine when I'm using a 'regular' connection. The first issue is that when I switch from cable to wifi, I have to restart the computer for the remote webdriver to work. But the main problem, is that when connecting to vpn, nothing works at all - the browser won't even open. Has anyone encountered anything like this in the past?
Let me know if more details are required..
Thanks :)
Chrome doesn't allow extensions while running /controlled by selenium. I end up using VPN application(hide me,norvpn) which globally change ip for the running applications on my machine.
I've got a Nexus 7 tablet with Android 4.4.2 and browsers Chrome and FireFox installed on it. When I open the website https://ib.sb24.com with it, it prompts me that the certificate is not trusted but when I open the same address with a desktop browser it's alright! Why is that?
[UPDATE]
By desktop I mean Windows and Ubuntu, Chrome and FireFox.
This looks like the server is configured wrong. It only sends a single certificate which is not signed by a known root, but instead by an intermediate CA. But the server forgets to add the needed intermediate certificates too.
The reason it works in your browser that you once browsed a site where the same intermediate CA was used and the browser cached the CA. Probably all browsers do that to help with such misconfigurations, but this does not help if the browser never visited a properly configured site with the right intermediate CA before visiting the misconfigured site.
If you don't believe me try to visit the same site with a fresh firefox profile, you will get the same problems.
Chrome most likely uses platform native store/list of trusted root certificate authorities therefore root CA which is trusted on your desktop platform (i.e. Windows) may not be trusted on Android platform.