I'm getting the below issue from CMSException while calling createSession()
Server Certificate Name doesn't match the URI Host Name value.
I'm using ssl://172.12.12.13:61617. The "Common Name" value is Machine0x and the IP address I used in the URI is listed in the SubjectAlternativeName list in the keystore:
Extensions:
#1: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
IPAddress: 172.12.12.13
]
Why isn't ActiveMQ checking the Subject Alternative Name value?
This similar question was asked but wasn't answered, and I don't have enough experience points to add a non answer comment so had to make a new post.
Also I got it to work by changing CN to the ip address so yeah it is indeed an issue with checking the SAN.
The ActiveMQ C++ client in unmaintained for years now and is likely not looking at the subject alternate name and only or not correctly matching the values. It's unlikely that anyone will fix this since the client is unmaintained. You might want to look into the Qpid Proton project and make use of one the the native AMQP client libraries there.
If you have Java clients using the ActiveMQ JMS client they can interact with AMQP, STOMP, or MQTT clients as the broker does do translation. See the broker documentation for more information on the wire formats and interop.
Related
Friendly Disclaimer: I am new to working with Keycloak and IdP in general. So it's likely that I use incorrect terminology and/or am more confused than I think I am. Corrections are gratefully accepted.
My question is conceptual.
I have a TLS certificate that is terminated on my host machine by my host company. My reverse proxy (Traefik) is picking up that certificate.
Which of the following proxy modes should I use now to be able to deploy Keycloak to production: edge, reencrypt or passthrough? (see here for relevant documentation)
I can pretty much rule out passthrough, because as I wrote, the TLS certificate is terminated on the server. But I am unsure if I have to bring my own certificate and reencrypt or if it is considered safe to go along with edge?
I have done my best to keep this question short and general. However, I am happy to share configurations or further details if needed.
As far as I know, most organizations consider a request to be safe when the proxy validated and terminated the TLS. It also removes the performance overhead (depends on your load). Unless your organization is going for Zero Trust for its internal network, using the edge should be totally acceptable.
I am quite new to ssl stuffs but I am afraid I can guess the final answer of the following problem/question:
We are building hardware (let's call them servers) that WILL have IP address modifications along there lifetime. Each Server must be reachable in a secured manner. We are planning to use a TLS 1.3 secured connection to perform some actions on the servers (update firmware, change configuration and so on). As a consequence we need to provide the server's with one certificate (each) so that they can state their identity. PKI issue is out of the scope of this question (we suppose) and we can take for granted that the clients and the servers will share a common trusted CA to ensure the SSL handshake goes ok. The server's will serve http connection on there configured (changeable) IP addresses only. There is no DNS involved on the loop.
We are wondering how to set the servers' certificates appropriately.
As IP will change, it cannot be used as the common name in the server's certificate.
Therefore, we are considering using something more persistent such as a serial number or a MAC address.
The problem is, as there is no DNS in the loop, the client can not issue http request to www.serialNumberOfServer.com and must connect to http://x.y.z.t (which will change frequently (at least frequently enough so that we don't issue a new server's certificate at each time))
If we get it right, ssl handshake requires to have the hostname (that's in the URL we are connecting to) matching either the commonName of the server's Certificate or one of its Subject's Alternative Name (SAN). Right? Here, it would be x.y.z.t.
So we think we are stucked in a situation in which the server cannot use it's IP to prove its identity and the client wants to use it exclusively to connect to the server.
Is there any work around?
Are we missing something?
Any help would be very (VERY) appreciated. Do not hesitated in cas you should need more detailed explanation!
For what it's worth, the development environment will be Qt using the QNetworkAccessManager/QSSlstuffs framework.
If you're not having the client use DNS at all, then you do have a problem. The right solution is to use DNS or static hostname lists (/etc/hosts, eg, on unix* or hosts.txt on windows eg.). That will let you set names appropriately.
If you can only use IP addresses, another option is to put all of your IP addresses into the certificate that the server might use. This is only doable if you have a reasonable small number of addresses that they might get assigned to.
Or you could keep a cache of certificates on the server with one address for each, and have part of the webserver start process to select the right certificate. Requires a bit more complex startup.
Edit: Finally, some SSL stacks (e.g. openssl) let you decide whether or not each particular verification error should be accepted as an error or that it can be ignored. This would let you override the errors on the client side. However, this is hard to implement properly and very prone to security issues if you don't bind the remote certificate properly it means you're subjecting yourself to man-in-the-middle or other attacks by blindly accepting any old certificate. I don't remember if Qt's SSL library gives you this level of flexibility or not (I don't believe so but didn't go pull up the documentation).
Went back on the subject 9 mont later!
Turns out there is an easy solution (at least with Qt framework)
Qt's QNetworkRequest::setPeerVerifyName does the job for us. It allows to connect to an host using its IP and verify a given CN during SSL handshake
See Qt's documentation extract below:
void QNetworkRequest::setPeerVerifyName(const QString &peerName)
Sets peerName as host name for the certificate validation, instead of the one used for the TCP connection.
This function was introduced in Qt 5.13.
See also peerVerifyName.
Just tested it positively right now
We are just starting to use google cloud data fusion for our ETL.
We have a use case to hit a server(self-signed) and get some info using the http-plugin in the data fusion product.
In my pipeline, i am turning off SSL verification to accept any certificates but getting an error
javax.net.ssl.SSLPeerUnverifiedException: Certificate for <on000120.aeo.ae.com> doesn't match any of the subject alternative names: []
Help text for the field also suggests to urn it off. See image.
Could someone please help?
I followed the instructions at https://www.freecodecamp.org/news/how-to-get-https-working-on-your-local-development-environment-in-5-minutes-7af615770eec/ to generate the key and crt files, so I had a file called v3.ext (which includes subjectAltName) and used that to generate the server.crt file. When I started my server with these files, I was able to deploy and run a pipeline using HTTP source from that local HTTPS server. How did you generate your crt and key? Would you please describe the plugins you're using?
I assume that issue that you've reported is not connected with Data Fusion runtime environment, but might be supposedly related the target HTTPS web server SSL/TLS configuration. Most of the time this issue occurs when the common name or SAN(Subject Alternative Name) of your SSL/TLS Certificate does not match the domain or address that you hit in HTTP call, hence this page is not listed in SAN's list and I can suppose that you didn't add any of domain names there.
As far as I know Data Fusion http-plugin, which is based on Java HTTP Client implementation, promotes HostnameVerifier class, that is used for URL's hostname and the server's identification hostname verification during establishing handshake between parties, you may take a look at the source code and find inherited method getDefaultHostnameVerifier() as well. Therefore, this can lead to the error, during http client intentions to launch SSL/TLS connection channel.
Even though, you turned of trust keystore certificate inspection in the plugin settings, the issue will persist because hostname validation still failing.
Hey out there to whoever is reading.
I have a question and it is regarding a UNI question which I can't seem to find the answer when researching so I thought i'd come to the experts of the web.
The question I'm asked is:
3. For which type of SSL certificate do you need a dedicated IP address?
I understand if asking for help with uni is against terms and conditions as I know some websites don't allow it. (But no harm in trying yeah?)
Thankyou to anyone who helps
For which type of SSL certificate do you need a dedicated IP address?
The context of the question is unknown and it is unknown what "type" of SSL certificate actually means in this unknown context. This could be domain validated vs. extended validated or it cold be X.509v1 vs X.509v3 or even other things. But, I'll try to explain the underlying concepts so that you should hopefully be able to come up with an answer yourself.
Validation of the certificate includes checking the target hostname (from the URL in case of HTTPS) against the subjects of the certificate. These subjects can be given as subject alternative names and/or as common name. Commonly none of these subjects has an IP address which means that commonly no fixed IP address is needed for a server using this certificate - all what is needed is that the server is actually reachable by the given hostname (i.e. DNS is properly setup) and that the client is using this hostname to connect to the server (instead of using the IP address only).
But it is possible to also include IP addresses as subject of the certificate. This is uncommon and no public CA (as found as trust anchor in the browser) will issue such a certificate any longer but private CA might do it. The validation is similar to the hostname, i.e. the client has to use the IP address in the URL to access the site and check that the IP address used matches any of the IP addresses given as subject in the certificate. Having a fixed IP will help in this case but actually the only requirement is that the IP address the client uses is included as any of the possible many subjects in the certificate. This means that the server might actually be reachable by different IP addresses as long as all of these are included as subject in the certificate.
I'm trying to find out more information on the details of two-way SSL authentication. What I want to know is what verifications are done when one client receives another's certificate. (See the Verify Circle in the image below)
Two way verification http://publib.boulder.ibm.com/infocenter/tivihelp/v5r1/topic/com.ibm.itim.infocenter.doc/images/imx_twowaysslcacert.gif
Does someone has a list of all of the steps? Is there a standards document I can be pointed to? Does each server implement it differently?
Mainly what I'm asking is... Does the server do a verification against the other server's hostname vs the certificates Common name (CN)?
As #user384706 says, it's entirely configurable.
The scenario you're talking about is one where a machine is both a server and a client (and is the client as far as the SSL/TLS connection is concerned).
You don't necessarily gain much more security by verifying that the connection originates from the CN (or perhaps Subject Alternative Name) of the certificate that is presented.
There are a couple of issues:
If the SSL/TLS server is meant to be used by clients that are both end-users and servers themselves, you're going to have two different rules depending on which type of client you're expecting for a particular certificate. You could have a rule base on whether the client certificate has the "server" extended key usage extension or only the client one, but this can get a bit complex (why not).
The client (which is also a server) may be coming through a proxy, depending on the network where it is, in which case the source IP address will not match what you'd expect.
Usually, client-certificate authentication relies on the fact that private keys are assumed to be kept protected. If a private key is compromised by an attacker on the server, the attacker may also have the ability to spoof the origin IP address when making the connection (or making the connection from the compromised server directly). This being said, servers tend to have private keys that are not password-protected, so it may help a little bit in case it was copied discretely.
I think some tools are so strict that they don't only verify the CN to be the FQDN of the incoming connection: they also check that it's the reverse DNS entry for the source IP address. This can cause a number of problems in practice, since some servers may have multiple CNAME entries in the DNS, in which case the CN would be legitimate, but not necessarily the primary FQDN for that IP address.
It all really depends on the overall protocol and general architecture of the system.
RFC 6125 (Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)), recently published, considers this scenario out of scope.
The closest reference I can think of is SIP.
Mainly what I'm asking is... Does the
server do a verification against the
other server's hostname vs the
certificates Common name (CN)?
This is configurable.
It is possible to configure strict checking and not accept connections from entities sending a certificate that the CN does not match the FQDN despite the fact that the certificate is considered as trusted (e.g. signed by a trusted CA).
It is possible to relax this and do not do this check and accept the certificate or delegate the decision to the user. E.g. IE shows a pop up warning saying that certificate's name does not match FQDN. Do you want to proceed anyway?
From security perspective the safest is to do strict verification