I am looking for a way to silently install a device or client certificate from an application in ChromeOS.
Is there a way to bypass the standard dialog when installing a pfx format certificate on Chrome OS?
Thanks,
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
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.
recently I was working with some facebook api and programs, and I upgrade my windows 8.0 OS to windows 8.1 OS and when I run the program I get this errors in IE11.
Content was blocked because it was not signed by a valid security certificate.
For more information, see “About Certificate Errors” in Internet Explorer Help.
how can I solve certificate issue? "how to add certificate if needed"
Open IE Tools > Internet Options > Content tab, then select the Certificates button. From there you can go through the applicable Cert types including:
Personal
Other People
Intermediate Certification Authorities
Trusted Root Certification Authorities
Trusted Publishers
Untrusted Publishers
As you mentioned "working with some facebook api and programs" check in the Untrusted Publishers section.
You can also right-click on the Windows icon and select Run, then type: certmgr.msc and go through your certificates in there as well.
I need to sign my Adobe AIR application which is a native installer. Right now I just have a Windows version, but soon I'll be porting it to other OSes including mobile OS.
My query is whether I need to get a separate code signing certificate for each one or is one enough? Also does 32-bit and 64-bit matter?
Verisign have categorized certificates for Windows (.exe) and Adobe AIR (.air and .airi) separately. So which one should I obtain?
CAs selling code signing certificates always pretend that you need different certificates to sign different kinds of applications. This is basically a scam. Most of the time the certificates are exactly the same, only the file format might differ. Even if the file format isn't supported by your code signing tool, there are ways to convert between different formats. So basically it doesn't matter which certificate you buy.
If you package your AIR app with a captive runtime, you can simply use a self-signed certificate with the adt tool. It's only important to sign the executable created with adt and your installer afterwards. If you create a native installer directly with adt, provide your certificate using the code signing options.
Under Windows, you should use Microsoft's signtool utility to sign the .exe file of your app and your installer if you want to package with a captive runtime. So I'd choose a code signing certificate for Windows. But as I said, it doesn't really matter (and there are cheaper options than Verisign).
Under Mac OS X ("Gatekeeper"), things are a little different. You can only use certificates issued by Apple. You have to enroll in the "Mac Developer Program" ($99 per year) to receive a code signing certificate for OS X. If you use a captive runtime, sign the application bundle created with adt using the codesign utility. If you create a .pkg installer, use the --sign option of the productbuild tool. There's a similar "iOS Developer Program" for iOS apps.
Under Linux, you don't sign packages with certificates issued by a CA. You simply sign them with a GPG key that you can create yourself for free. You have to publish your public GPG key so your customers can make sure that your packages are valid, though.
For Android apps, you can simply use a self-signed certificate, AFAIK.
32-bit and 64-bit apps can be signed in exactly the same way. You don't need separate certificates. But adt will only create 32-bit apps anyway.
I'm having issues with creating an AIR file from an Adobe AIR HTML/JavaScript project.
I've installed the Adobe AIR Extension for Dreamweaver CS5.5 and I also have the latest x86 version of the Java Development Kit installed (which should include the Java Runtime Environment). I'm using Windows 7 (x64).
After self-signing a digital certificate through the extension, I attempted to build the project into an AIR file. However, I encountered this dialog:
There was an error connecting to the timestamp server. You may not have a connection to the network, or the server itself may have a problem.
Click Retry to try again.
Click Disable to create the AIR file with timestamping temporarily disabled. If you disable timestamping, the AIR application will fail to install when the digital certificate expires.
I checked my proxy settings in both the Java control panel and Internet Explorer, but nothing should interfere with Dreamweaver's connection. I also disabled Windows Firewall and tried another network connection, both to no avail.
After some research, I found a suggestion stating that the Geotrust timestamp server may be temporarily down. Despite this, the error still persists after I've waited a day.
Can somebody help me resolve this problem? Thanks.
I found the solution.
Java SE version 7 was installed on my computer, but version 6 was the latest version supported by the Adobe AIR tools. I downgraded to version 6 and the timestamp generation went smoothly.