I have 2 microservices in different server and i tried to hit api using http from one to other. it get me like timeout response [server not response]. And i tried hit api using https and it get me error like "you need certificate".
My question is does http need ssl or not ?
Thanks
HTTP no, HTTPS yes. Many blanks to satisfy system...
Related
I have setup a nginx proxy to pass https url to internal http neo4j web. I can reach the neo4j login page without any issue, but I am forced to use the neo4j+s/bolt+s interface.
Just wondering how I can configure nginx to remove any ssl related info via proxypass module, in order to login in neo4j with ws, no wss?
Thanks,
Chance
I managed to get rid of wss by adding another nginx proxy to set the https url as upstream server in location.proxy_pass. It won't show wss/neo4j+s/bolt+s any more once you visit the web by the http url. Hopefully it will help for anyone has the similar issue as me.
I use a site in IIS in https. I use a software, that use a 'HTTP Sender' connector, to connect to my rest. I need to convert from HTTP to HTTPS. I have seen that STUNNEL is usually used. I saw that it can be done in stunnel.conf. But I can I do?
If a client is requesting a domain that does not have a valid CA signed certificate and the server not intend on supporting HTTPS but does support HTTP for this domain, what is the best way to handle this in the web server. Note, the server does handle requests for SSL (HTTPS) on other domains so it is listening on 443.
Example where this would apply is for multi sub-domains where the sub-domains are dynamically created and thus making it extremely difficult to register CA signed certificates.
I've seen people try to respond with HTTP error codes but these seem moot as the client (browser) will first verify the certificate and will present the hard warning to the user before processing any HTTP. Therefore the client will only see the error code if they "proceed" past the cert warning.
Is there a canonical way of handling this scenario?
There is no canonical way for this scenario. Clients don't automatically downgrade to HTTP if HTTPS is broken and it would be a very bad idea to change clients in this regard - all what an attacker would need to do to attack HTTPS would be to infer with the HTTPS traffic to make a client downgrade to unprotected HTTP traffic.
Thus, you need to make sure that the client either does not try to attempt to access URL's which do not work properly (i.e. don't publish such URL's) or to make sure that you have a working certificate for these subdomains, i.e. adapt the processes for creation of subdomains so that they not only have an IP address but also a valid certificate (maybe use wildcard certificates).
Considering these websites don't have to work with SSL, the webserver should close all SSL connections for them in a proper way.
There is no canonical way for this, but RFC 5246 implicitly suggests to interrupt the handshake on the server side by using the user_cancel + close_notify alerts. How to achieve this is another question, it will be a configuration of the default SSL virtual host.
user_canceled
This handshake is being canceled for some reason unrelated to a
protocol failure. If the user cancels an operation after the
handshake is complete, just closing the connection by sending a
close_notify is more appropriate. This alert should be followed
by a close_notify. This message is generally a warning.
If you are dealing with subdomains, you probably can use a wildcard certificate for all of your subdomains.
Adding the CA certificate to your client will remove the warning (that's what companies do, no worry).
When hosting with Apache, for example, you can use VirtualDocumentRoot to add domains without editing your configuration. Have a look at the solution provided here : Virtual Hosting in SSL with VirtualDocumentRoot
I was just wondering this small little question. I know it is irreverent to coding, but I just had to know quickly.
If you type in http:// for a https:// will it still take you to the correct place?
That is mostly dependent on the server configuration. The server has to accept the initial HTTP request and be configured to redirect the client to an appropriate HTTPS url.
That being said, there are some Internet standards related to automating HTTP-to-HTTPS upgrades. HTTP Strict Transport Security and Upgrade Insecure Requests allow an HTTP/S server to tell clients that it wants them to automatically use HTTPS for all subsequent requests. If a client visits an HSTS/UIR-enabled server, it will receive a normal HTTP response with additional HSTS/UIR-related headers. If the client supports HSTS/UIR, it will then know to automatically send all subsequent HTTP requests to that same server using HTTPS, and in the case of UIR also treat any received HTTP URLs as if they were HTTPS URLs.
Got a problem with squid. I'm using 3.1 version with my own redirector.
My problem was when a client for example request https://twitter.com (with https) but somehow got a logic with my redirector that twitter.com is invalid page so i redirected this request to my invalid page. Let say 302:http://mydomain.com?invalid=twitter.com, in this stage process will not continue and browser will say "HTTP gateway failed".
So, my theory is when a request is https redirected to http, squid will not work. Is there any configuration i need to be done so that it will work?
Thank you guys..
RFC 2817 isn't very clear about the behavior of CONNECT and redirect. I think that most of the browser won't accept a redirect as a reply to the CONNECT method. So, there is no way to do what you want.
Is not an Squid issue, is a protocol/browser issue.
well, i think the best way to redirect is when:
- if the request is https the response should be https
- and if the request if http response should be http
that's the best way i can't think at the moment...