I have an application running in a tomcat server which is behind a NginX which has a proper certificate. When I try to access this app using Chrome in Mac OS X, I get the "select a certificate to authenticate yourself" pop-up in the browser.
I want to avoid this. To do it, I need to know why this occurs. Can someone explain why this is happening?
That's because your Tomcat server requires TLS client authentication to established the connection. You should change the Tomcat server configuration to disable TLS client authentication.
Related
Any help or hint would be greatly appreciated it!!
I have windows 11 Pro.
I installed openshift.
I did "crc setup" and I did "crc start":
INFO Adding crc-admin and crc-developer contexts to kubeconfig...
ERRO Cannot update kubeconfig: x509: certificate has expired or is not yet valid: current time 2022-05-24T00:01:26-04:00 is after 2022-01-13T22:29:55Z
Started the OpenShift cluster.
The server is accessible via web console at:
https://console-openshift-console.apps-crc.testing
I get the following error when I tried to login:
C:\Users\Albert Lam>oc login -u developer https://api.crc.testing:6443
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): n
error: The server uses a certificate signed by unknown authority. You may need to use the --certificate-authority flag to provide the path to a certificate file for the certificate authority, or --insecure-skip-tls-verify to bypass the certificate check and use insecure connections.
C:\Users\Albert Lam>oc login -u developer https://api.crc.testing:6443
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y
I had the same problem and it was caused by an old certificate that was expired and had nothing to do (VMware one) with Openshift.
I've found the problem by viewing the certificate inside my chrome browser after navigating to https://console-openshift-console.apps-crc.testing.
The correct certificate should have *.apps-crc.testing as CN, but mine has another one.
I suggest you to find the wrong certificate and delete it if expired.
On windows, for VMware you can find it inside C:\ProgramData\VMware\SSL.
On Windows you can look for certificates by using the "manage certificates" app.
I just installed Couchbase Server 3.0.2 on Windows 8.1. The Installation went through successfully but I am unable to access http://localhost:8091/index.html.
"Google Chrome's connection attempt to localhost was rejected. The website may be down or your network may not be properly configured."
I tried to check if anything listening on that port using the command.
netstat -an -p tcp
But found nothing is listening on that port and the closest port i found was 8092, so thought may port has changed so when i try to browse on that port i got a json response as below.
{"code":404,"status":"fail","message":"controller_not_provided","ResultDate":"2015-02-06T17:13:23.2551859Z","Progress":-1,"Result":"No controller provided."}
please check the couchbase service form the windows control panel. sometimes it will not start the service automatically ,it may be manual. start the service manually , if not started then check the localhost url.
you can also start the service form the desktop icon. double click on the couchbase icon it will start the service automatically and it will open the url in your default browser.
if still facing the problem not able to start the couchbase server , follow the
.link
it describe each and every steps of the couch base installation process.
The scenario:
You're behind a proxy server on Windows. You've configured TortoiseHg to use a proxy server; that is you've entered a server name/IP and port number. You are able to connect to the internet using Internet Explorer. But when you try to pull or push and it produces the error message "SSL error: unknown protocol".
(I plan to answer this myself.)
The cause is that Internet Explorer is using an automatic proxy configuration script and TortoiseHg is using a particular proxy server. IE is not using the same proxy server because the automatic script picked a different proxy server.
The solution is to enter the proxy server used by TortoiseHg in IE's connection settings, or figure out which proxy server you're using at the moment and tell TortoiseHg to use that one. You may need to browse an external web site before TortoiseHg can connect.
You can figure out which proxy server you're using by browsing with IE and then running the DOS command:
netstat
and you'll see some connections in the Foreign Address column on port 80 or 8080 (common proxy server ports).
In addition to your excellent tip, I offer one more...
If your company is using an automatic proxy script, then the proxy used for web browsing may not be the one you need for Mercurial. Thus if you try the proxy you find via netstat, and you get "getaddrinfo failed" errors in tortoise, then try this...
Get the proxy script address: IE->config->Internet Options->Connection->LAN ?Settings. Copy the url from the "Address" box.
Browse to that address and save the file to disk.
Open that file in notepad and scroll to the end, it probably ends with something like-- return "PROXY ipaddresshere:port" that's the IP and port you need.
Plug that IP and port into tortoise: right-click the repo, click settings, click proxy, put the ip and port into the Host field. I generally don't need user and password so try without it first.
I have a testapp consisting of an HTML5/WebSocket client and an HTTP/WS server. Both servers are in C#; the HTTP server is my own simple thing and the WS server is also homebrew based on concepts from http://nugget.codeplex.com/. HTTP server is listening on 0.0.0.0:5959 and WS server on 0.0.0.0:5960 (accept connections from any client, but on different ports).
My index.html includes some JavaScript that opens a WebSocket to 'ws://'+document.location.hostname+':5960/' (that is, to the same IP address that the webpage came from, but on port 5960). The WS server sends sample data every 100ms. All in all, it's a pretty straightforward demo.
I'm using Chrome 12.0 on Windows7.
I've found that the HTTP server works from any client, either a browser on my machine pointed to 127.0.0.1:5959 or localhost:5959, AND it works when any machine (mine or a remote machine... "remote" being a different PC on my desk :) hits my server machine's work-internal 10-net address 10.122.0.159:5959. Everything works as expected in HTTP land.
However, the WebSocket only works on 127.0.0.1 and localhost; remote machines can successfully fetch HTML from 10.122.0.159:5959 but the WebSocket will NOT connect to 10.122.0.159:5960. In fact, when I point my local browser to it's own 10-net address (10.122.0.159:5959) I get the same result - HTML loads but WebSocket does not connect.
Any ideas as to why this might be happening?
Does CORS require that the WS be using the same port as the HTTP request originated from? If so, is there a special exception to the rule for 127.0.0.1?
Many thanks,
-Dave
Update
It seems to be caused by a proxy server blocking ws:// requests. Our company employs a proxy server for content filtering and all the usual stuff, and our browsers are configured to use it.Chrome uses IE's proxy settings, and IE's default settings are for localhost to not use a proxy server. When I check the box to have local connections also use the proxy server, my ws:// requests to localhost get blocked. Conversely, when I uncheck the "use proxy server" box my server does rx the WS request. Similarly with the remote machine, if I turn off the proxy on the remote machine my server does rx the ws:// request.
So it's a proxy thing, not a CORS or socket thing, and now I'm off to explore proxy settings with our IT folks.
There is no WebSocket limitation on cross-origin except what is governed by the CORS security in the handshake.
It sounds like something is wrong with your WebSocket server and it is only listening on localhost for connections. I would add some debug output to the OnClientConnect routine in Nugget (WebSocketServer.cs) so you can see when socket connections happen. If you really think it isn't a problem with the server then I would suggest using wireshark and comparing the localhost connection to the remote connection.
Also, if you are using the SilverLight WebSocket prototype (README) in IE 9, then you are restricted to ports 4502-4534 for WebSocket connections. It's possible that for localhost this restriction is lifted.
It is/was indeed a proxy thing.
Rather than asking our IT folks to make changes (good luck with that, eh?) I simply turned off proxy for 10.122.0.159 ([Howto for IE/Chrome][1]). I briefly experimented with turning it off for the ws:// protocol but couldn't get it to work, so for now just opening that one IP address does the trick.
Using as3crypto's TLSSocket it should be possible to connect to an SSL server. However, my server uses a self-signed certificate. How can I configure the client to accept that certificate?
I'm assuming I need to hard-code the cert's fingerprint in the client somewhere (or get it there some way). That's ok.
If as3crypto doesn't support this, other options are welcome.