https://www.hi-todd.com/websocket/
I have created one demo with MQTT protocol and it is working fine with HTTP connection. But when I tried to change HTTP to https then it is getting a connection error.
I have added certificate path in mosquitto.conf file. Let me share with you Mosquitto config path.
# WebSockets over TLS/SSL
listener 8083
protocol websockets
cafile /etc/mosquitto/ca_certificates/ca.crt
certfile /etc/mosquitto/ca_certificates/hi-todd_com.crt
keyfile /etc/mosquitto/ca_certificates/hi-todd_com.p7b
I have used below library code.
https://www.cloudmqtt.com/docs-websocket.html
Now we've fixed all the other issues.
The certificate you are using has a CN of hi-todd.com and has alternate CNs of
DNS:hi-todd.com, DNS:www.hi-todd.com
This means it's only valid for those hosts. In your config.js you are referencing the host by it's IP address so it will not match the certificate. This will cause the browser to reject the connection as insecure.
To fix this make your config.js use the hostname not the ip address.
Related
I have build a Go server using Echo framework, i get TLS certificades and a domain name, but when i try a request i get the message "Client sent an HTTP request to an HTTPS server." and when i try acces the server from the IP address of the EC2 using the port 443, it says that the connection is not secure:
And when i change the server to the port 80 to acces through the domain name, i get the following error:
I'm starting the server using the StartTLS func
e.Logger.Fatal(e.StartTLS(":80", "/etc/letsencrypt/live/anltcsprod.enrtt.com/fullchain.pem", "/etc/letsencrypt/live/anltcsprod.enrtt.com/privkey.pem"))
Is it something wrong with my domain or certificade?
Port 80, by default, communicates over HTTP. 443 is reserved for HTTPS traffic. Assuming nothing else is wrong, you should be able to simply change your e.StartTLS() to this:
e.Logger.Fatal(e.StartTLS(":443", "/etc/letsencrypt/live/anltcsprod.enrtt.com/fullchain.pem", "/etc/letsencrypt/live/anltcsprod.enrtt.com/privkey.pem"))
For example localhost:4000
Instead use https://localhost:4000
I am trying to do load testing with JMeter for a spring boot application running locally on port 8080.
Request configured is a GET request, and protocol is https. I get following error message:
javax.net.ssl.SSLException: Unsupported or unrecognized SSL message
at java.base/sun.security.ssl.SSLSocketInputRecord.handleUnknownRecord(SSLSocketInputRecord.java:439)
at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:184)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
Any input on it would help?
Your are most probably using https to hit the server while you should use http as port 8080 is usually for http.
Otherwise change port to 8443 for https
Did you cross-check the port number on JMeter?
make sure that the same port is defined in JMeter as well.
https://localhost/application/sub/url
For the above URL, the port number is 443 which is the default port for https
https://localhost:8080/application/sub/url
Whereas the above URL uses 8080 for communication.
Please make sure the correct port has been specified.
Additionally, also note that that JMeter itself doesn't allow unsigned certificates. Make sure the certificates are properly signed via Certificating Authority.
I'm reading the spec and trying to understand exactly when 421 might be returned. An example is given but I don't completely understand it.
Background
The spec establishes two conditions that allow for connection reuse:
For TCP connections without TLS, this depends on the host having resolved to the same IP address.
and
For https resources, connection reuse additionally depends on having a
certificate that is valid for the host in the URI.
If the certificate used in the connection has multiple subjectAltName or any of the subjectAltName is a wildcard, then the connection can be reused for any request that has a hostname that is in the list of subjectAltNames or matches any of the wildcards.
Specific Example In the spec
In some deployments, reusing a connection for multiple origins can
result in requests being directed to the wrong origin server. For
example, TLS termination might be performed by a middlebox that uses
the TLS Server Name Indication (SNI) [TLS-EXT] extension to select an
origin server. This means that it is possible for clients to send
confidential information to servers that might not be the intended
target for the request, even though the server is otherwise
authoritative.
Please explain where my understanding of this example is wrong:
An https connection is established to a middlebox with a request that has domain x.com. The middlebox has IP address 1.2.3.4 and x.com resolves to that address. Using SNI, the TLS handshake has x.com and the middlebox returns a certificate valid for that domain. All messages on this connection go from the client to the middlebox or from middlebox to client. Applicaiton level messages from client to middlebox are forwarded by middlebox to an origin on a different connection. Messages from origin to middlebox are forwarded to the client. If the connection is to be reused, meeting the two conditions discussed above is not enough. Specifically, for a request with domain y.com: if y.com resolves to 1.2.3.4 and the middlebox has a certificate valid for y.com, there can still be a problem. Because the original connection did its TLS handshake using x.com and because handshakes are only done at the beginning of new connections, there is no way establishing an https connection that would get the certificate for y.com. So the client incorrectly sends a request on the same connection to y.com. The middlebox rejects the request because the certificate associated with the connection is valid for x.com - not y.com. (The x.com certificate is only valid for x.com and the y.com certificate is only valid for y.com).
None of your examples will trigger a 421 as far as I can see.
Yes you are correct that a connection needs both the IP address and the SAN field in the certificate to be valid - without those a connection should not be reused.
So what would trigger a 421? As far as I can tell it will be mostly due to different SSL/TLS setups.
For example:
Assume website A (siteA.example.com) and website B (www.example.com) are both on same IP address. Assume website A has a wildcard cert for *.example.com and website B has a specific one. Could be a few reasons for this: for example it serves an EV cert for the main website which can't be a wildcard cert.
So cert A covers website A and website B. As does the IP address. So if you are connected to website siteA.example.com, and then try to connect to www.example.com then technically, by HTTP/2 standards, you could reuse the connection. But we wouldn't want that to happen, as we want to use our EV cert. So the server should reject with a 421. Now in this example the webserver is able to distinguish the correct host and has a valid cert for that host so could, in theory, serve the correct content under the wildcard cert, instead of sending a 421 - but since that wildcard cert is not defined for that virtualhost it should not do this.
Other examples include if you have different ciphers set up on different hosts. For example site A has super lax HTTPS config, because it's not really secure content and they want to reach even legacy browsers, but site B has super secure config and only accepts the latest TLS version and strong ciphers. Here you obviously wouldn't want them to reuse the same connection details. See here for a real would example of this.
Also this is only an issue for certain browsers, depending on how they decide to connection share. This page shows how different each of them do this (at least at the time of this blog post not not aware of anything changing since then): https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/
Also note that some bugs will exist with this (for example: https://bugs.chromium.org/p/chromium/issues/detail?id=546991). Best advice is: if you do not want connection sharing to happen, have a different IP address and/or ensure no overlaps in certificates.
I am using
Apache
Ruby and Ruby on Rails 3
Mac Os running "Snow Leopard"
and I would like to use HTTPS on localhost for my domains and sub-domains.
I have already set everything (I think correctly):
I generated a wildcard certificate for my domains and sub-domains (example: *.sitename.com)
I have set base-named virtualhosts in the http.conf file listening on port :433 and :80
My browser accept certificates also if it alerts me that those aren't safe and I can have access to pages using HTTPS
From the official Apache guide I read that it is not possible to do that using name-based virtualhost, but I also read someone that made that in some way (what?! I don't understand...).
So, is it possible or not to use HTTPS in localhost for multiple domains and sub-domains? If so, what I must "to do"\"to check" for working with that?
UPDATE for #sarnold
typhoeus appears to use libcurl, and
libcurl appears to support SNI -- is
your version of libcurl new enough to
support SNI? Does typhoeous know how
to enable it? (Do clients of libcurl
need to "enable" it SNI themselves?)
I think so because I can access all sub_domains over HTTPS and libcurl should be updated:
curl -V--version
curl 7.21.2 (x86_64-apple-darwin10.5.0) libcurl/7.21.2 OpenSSL/1.0.0c zlib/1.2.5 libidn/1.19
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: IDN IPv6 Largefile NTLM SSL libz
# Typhoeus request
Typhoeus::Request.get("https://<sub_domain_name>.<domain_name>.com/")
How can I check if "Do clients of libcurl need to "enable" it SNI themselves?"?
The techniques for doing name-based virtual servers with SSL/TLS aren't great choices, but the Server Name Indication extension allows browsers to request a specific site by name, allowing different certificates to be used with different sites. Not all browsers support SNI yet.
Though one might ask what value there is is in having multiple certificates if they are all served out of the same process with the same privileges, anything to improve the user's TLS experience has to be worth the hassle. :)
I would like to use the net/imap library in ruby behind a authenticated proxy, I was starting to dig in and I'm wondering if there is a way to do this already or if I need to make my own version of the net/imap library that supports a proxy?
It is possible to tunnel any socket connection through a HTTPS proxy server.
To do this:
open a socket to your proxy server
send "CONNECT hostname : portnumber HTTP/1.0\n\r\n\r\n"
read from the socket until you see the end of the HTTP headers (2 blank lines)
your socket is now connected
Here is a ruby example of such a tunnel.
Reasons this will fail:
most network admins will only allow CONNECT to port 443
proxy server has proxy authentication
The easiest way to hack libraries that don't support proxy information is to replace Net::HTTP with an instance of Net::HTTP::Proxy:
# somewhere before you load net/imap
proxy = Net::HTTP::Proxy(address, host)
Net.class_eval do
remove_const :HTTP
HTTP = proxy
end