Is it possible to import a root CA cert into JxBrowser, or otherwise disable Chromium's certificate checks?
We want to use JxBrowser in OWASP ZAP which is a security tool that allows you to intercept HTTPS traffic by re-signing it with its own root CA certificate.
By default JxBrowser ignores certificate errors and with v6.11 it all worked fine. With 6.12 we are no longer able to access google.com when proxying through ZAP, which I'm guessing could that be due to certificate pinning.
We want to be able to use JxBrowser 'out of the box' so that our users dont have to manually import the ZAP root CA into their machines certificate store.
Any suggestions for ways we can make this work gratefully received.
JxBrowser doesn't provide such functionality. It allows filtering SSL certificates, decide whether invalid certificate can be ignored or not, allows accessing certificate information, etc., but it doesn't allow setting your own root CA certificate and use it for HTTPS.
We do have similar feature request in our backlog. Please submit feature request via your account in JxBrowser Help Center, so we could associate your request with appropriate task in our issue tracking system. Being able to associate your request with the feature request, we can notify when this functionality is implemented and available for download.
UPD: The feature has been implemented in JxBrowser 6.14. The following example demonstrates how to use the new API:
browser.setDialogHandler(new DefaultDialogHandler(view) {
#Override
public CloseStatus onSelectCertificate(CertificatesDialogParams params) {
X509Certificate x509Certificate = loadCertificate();
params.setSelectedCertificate(new Certificate(x509Certificate));
return CloseStatus.OK;
}
});
Related
I want to verify my pact against an API that has an https endpoint.
My request is timing out when I run the pact.
Does Pact.Net supports https verification or am I missing something?
Yes, it should be able to do this.
I'm going to guess that the https target is using a self-signed certificate. To work around that you can specify the following env vars to fix this:
To connect to a Pact Broker that uses custom SSL cerificates, set the environment variable $SSL_CERT_FILE or $SSL_CERT_DIR to a path that contains the appropriate certificate.
(see also https://github.com/pact-foundation/pact-ruby-standalone/releases)
You could enable debug logging to see what the process is doing, consult the docs on how to do that.
I am transfering a website and when am navigating to a page my url is changing from HTTP to HTTPS. Here am getting the Privacy Error message in my browser.
How can I avoid this in moovweb transformation?
Let’s take the example of http://mlocal.erin.ne.jp/
When we are choosing Japanese version its pointing to https://mlocal.erin.ne.jp/jp but in my browser when its moving to secure site am getting Private error.
How can we set-up the config to avoid such error?
I tried with ssl_whitelist but no luck :(
{
"host_map": [
"$.erin.ne.jp => www.erin.ne.jp"
],
"ssl_whitelist": [
"erin.ne.jp",
"erin.ne.jp/jp",
"https://erin.ne.jp/jp"
]
}
Thanks in advance !!!
The ssl_whitelist configuration option is only necessary if the website you are trying to transform has invalid certificates. Typically, this might be a staging website where it is known that the certificates are invalid. So this option is unrelated to the problem you are seeing.
During local development, the Moovweb SDK will load a self-signed SSL certificate for the local domain. This is provided as a convenience to simulate SSL traffic.
When you hit https://mlocal.erin.ne.jp, that is your local server with invalid SSL certificates. Because there is no chain back to a root certificate authority, your browser will not trust the certificate.
If you acknowledge the error, you will be able to proceed. I am only recommending this because this is a local development situation only. During normal web browsing, take care when you see similar messages.
This is completely separate from production-ready projects that will be hosted on the Moovweb cloud. In production, you will have to acquire valid SSL certificates that matches the production domain name you select (typically m.erin.ne.jp, t.erin.ne.jp, or www.erin.ne.jp for a single-domain project). Once this is set up properly, you will not see any SSL certificate errors on your production domain.
I have been trying to configure a website I deployed on my local server with a self signed certificate for development purposes. The address I want my website to work for is example.company.local.
After I genrated a certicate using SelfSSL, I copied it to the Local Machine store in both Personal and Trusted Certifciate root . But I get the error "Server's certificate does not match the url" when I try to reach the url. Though I can ignore it, I understand that the cert auth is failing and I want to fix this. I am listing the steps I followed
Generated self signed cert using selfssl /N:CN=example.company.local /V:9999. This added the certiciate to my Personal store on Local Machine
From the mmc (type mmc in Run), I add the cert generated above to the to Trusted Root Certificate folder from the Personal folder
Restart IIS
Please suggest where I am going wrong. The url I give is https://example.company.local, but it refers to a localhost certificate.
Please try this guide. From the comments on the page it seems to be working but I did not test it.
If by any change there is still a problem I would suggest to use xca. It is built on top of openssl, has very nice GUI and has templates for CA, SSL server and SSL client. Documentation can be found here.
I'm facing non-trivial problem with webapi.
I'll describe here shortly what the problem is, later I'll present two approaches that are potentially "to discuss", and at the end I'll tell you what my thoughts are.
THE PROBLEM:
What I'm facing is such a scenario that I've a RESTFul webapi's application that has two controllers. Let's say "MutualAuthController" and "NonAuthController". I would like to host it at IIS in such a manner that MutualAuthController will be mutually secured (SSL with client certs) while the NonAuthController is not secured at all. So let's say I can access: somehost/MutualAuth (over HTTPS) and somehost/NonAuth (over HTTP)
FIRST APPROACH:
I do not have any problems with setting correct security. I have a problem with "unsecuring" the second controller.
Once I've ticked "Require SSL" and "Require Cert" in IIS' SSL Configuration, network traffic is trivial: clientSayHello to server, server responds with server hello and REQUIRE CLIENT CERTIFICATE. Such a client sends response with client certificate. Now it's obvious that the second controller acts the same way which is not the case. I want to make it work on basic http endpoint. So once I've spent few hours of research I've gave up and went other way because I simply do not know how to "unsecure" only a part of an SSL secured web application.
SECOND APPROACH:
The other approach was to configure IIS in this way that it does not require SSL but accepts client certificates. Hence, MutualAuthController could have some POSTMethod which requires HTTPS -> just like it is described by Mike here: http://www.asp.net/web-api/overview/security/working-with-ssl-in-web-api
, while the NonAuthController will not have such an attribute. In such an attribute I could then call Request.GetClientCertificate() and make my validations. Seems easy right?
THOUGHTS:
Everything is so obvious and fine beside one crucial fact. Client is not sending certificate at all because transport layer did not required it. The SSL Handshake in this case is set by IIS and it's underlaying stack.
Has anyone faced similar problems? Or maybe is there any chance to pass client certificate even if server (IIS) didn't wanted it?
Added after few tens of minutes...
BTW: I've just found something nasty in my very very tired mind. Going with first approach.
Could it work that I would create some BypassIISHttpsAttribute that will override OnAuthorization method and let it pass if it is HTTP?
For example in this way:
public class BypassIISHttpsAttribute : AuthorizationFilterAttribute
{
public override void OnAuthorization(HttpActionContext actionContext)
{
if (actionContext.Request.RequestUri.Scheme == Uri.UriSchemeHttp)
{
base.OnAuthorization(actionContext);
}
}
}
Thank You very much for reading all content and maybe for some replies? :)
If you are using IIS 7 or above, you can create two rewrite rules: one for the secure controller and one for the other. Use this link to go from http to https. Then reverse it for the other controller. You will need to allow unsecure traffic so don't require SSL. Just rewrite the URLs to the correct security method based on a regular expression.
I'm migrating a web app from an IIS 6 server to an IIS 7 server and I'm having some troubles with getting the client's certificate.
The piece of code that I'm using looks like this:
HttpClientCertificate cert = Request.ClientCertificate;
if (cert.IsPresent)
{
...
}
On the IIS 6 server, the cert.IsPresent is always true. However, on the IIS 7 box, it is always false. Both tests were done with IE 8 from the same computer. The only change was the Server URL, so the client should be setup correctly.
I'm not getting any SSL connection errors (I'm accessing the page via https) and I've set the SSL Settings -> Client certificates: to Accept (same as the IIS 6 configuration).
I've gone through and configured the IIS 7 server as closely as I could to the IIS 6 server, but I'm still not getting the cert.
Are there other areas that I need to look at for configuration?
Also, if I set the Client certificates: to Required, I get a 403.7 error on the IIS 7 box. I don't know if that is a symptom, but just in case the information is useful...
Basically it boils down to the fact that the client can't provide the client certificate.
That's why you get the 403.7 error when you require it.
I believe you need this:
http://blogs.msdn.com/b/puneetgupta/archive/2009/08/03/where-is-the-client-certificates-ui-in-iis-7-0.aspx
Please let me know if this helps.
I came across this question while looking for more information about how to get certificates in IIS 7 vs. IIS 6. I see that #whosrdaddy's solution worked for the asker. There is something else that I had to hunt down.
One of the differences between IIS 6 and IIS 7 is that IIS 6 has the "Directory Security" tab in each web site's configuration. In order to make the web server request certificates in IIS 7, you must click on the "SSL Settings" feature for the Web Site or Virtual Directory you are configuration to see the "Client certificates:" setting: Ignore, Accept, or Require.
Make sure that this is not set to "Ignore", or else you will never get your certificates to work!
The IsPresent == false can be caused by several different things, both related to the server and the client. We hit everyone of these on the way to finally fixing these and I will detail each....
Server Issue #1 - The client cert passed in has 1 or more certification paths that do NOT exist on the server. Open the cert go to certification path (tab) and make sure each of the root authorities are in the SERVERS trusted root certificate authorities. Note, you DO NOT need to install the cert on the server just the root authorities public keys under Certificates (Local Computer) \ Trusted Root Certification Authorities.
Server Issues #2 (previously mentioned solution) - In IIS, for the site, make sure the SSL Settings are set to Accept OR Require (never ignore). The benefit of using Require is that the IIS logs will show you are 403 7 error where as Accept will just get your the IsPresent == false but with a 200 http code.
Client Issue #1 - Same as server issue #1, got to trust those authorities!
Client Issue #2 - You have the trusted root authorites but NOT the private key for the cert itself. Make sure you install the pfx (private key) into the cert store not the public key (.cer). You can also see if you have the private key by double clicking the cert in the cert store and on the general tab you should see a message saying as much.
Client Issue #3 - You put the cert in the wrong place. Probably best to place your cert in Certificates (Local Computer) \ Personal \ Certificates, rather than (current user). This will make the cert available to process accounts that are running your code and actually need access to it.
Client Issue #4 - Right mouse click the cert (in the store not a .cer file) --> All Tasks --> Manage Private Keys... and make sure the process account running your code has "Read" permission. A quick test of this (but not recommended for production use) is to add "Everyone" as read to see if this is your issue.