I am creating a consumer using soladmin. consumer is an ssl consumer and the operational state is down. I am getting an error saying "local ssl Handshake failed : Server certificate verification failed : not trusted common name"
any have any ide in what situations I get this error.
The error indicates that the Solace appliance/VMR is not able to verify the common name of the server certificate of the REST consumer.
You can get rid of the error by either:
Adding the common name of the REST consumer's SSL certficate as a trusted common name for this specific REST consumer.
a) Right click the REST consumer in SolAdmin.
b) Left Click "Manage SSL Options"
c) Add the correct trusted common name.
Disable "Enforce Trusted Common Name" on the VPN.
a) Login via the CLI
b) Enter the following series of commands, replacing myVPN with the actual name of your VPN.
solace> enable
solace# configure
solace(configure)# message-vpn myVPN
solace(configure/message-vpn)# rest
solace(configure/message-vpn/rest)# ssl server-certificate-validation
solace(...est/ssl/server-certificate-validation)# no enforce-trusted-common-name
c) Verify that "Enforce Trusted Common Name" is now disabled. Once again, replace myVPN with the actual name of your VPN.
solace> show message-vpn myVPN rest
Message VPN: myVPN
REST SSL Server Certificate Validation
Enforce Trusted Common Name: Disabled
Maximum Chain Depth: 3
Validate Certificate Dates: Enabled
Related
I'm using Angular 14 and the ngx-mqtt front-end lib.
Here's my connection string which works fine:
getEmqxCloudConnection(): IMqttServiceOptions {
return {
hostname: 'xx.xx.xx.182',
port: 8083,
path: '/mqtt',
clean: true, // retain
connectTimeout: 4000,
reconnectPeriod: 4000,
clientId: 'HarBrowserTest1',
username: 'myUser',
password: 'myPass',
protocol: 'ws',
connectOnCreate: false,
};
}
As per their Broker dashboard the available ports are:
Ports: 1883(mqtt), 8883(mqtts), 8083(ws), 8084(wss)
I have already imported our SSL Certificate into the EMQX Dashboard, yet when I change my conn string to port: 8084 and protocol: 'wss' - IT DOESN'T CONNECT !
They have some screenshots here showing their Client Tool, but for reason every one shows port=1883 (a mistake maybe). https://docs.emqx.com/en/cloud/latest/connect_to_deployments/mqttx.html#connection-configuration
In my Chrome browser network tab, here's what I see for the std insecure ws - A successful ws conn to the Mqtt Broker.
Here is the certificate UI which I used to imported the PEM-Encoded cert body and key:
This will most likely be down to the certificate you have used for the broker.
First unless you have created the certificate just right (using the correct SAN entries) that include the IP address as the principal for the certificate, then the connection will get rejected because the certificate doesn't match the hostname/IP address the broker is using to connect.
Second, if it is a self signed certificate then the browser will just reject it, unless you have manually imported the CA (or if it really is self signed the cert it's self) into the browsers trust store and marked it as trusted. The browser will NOT show you a warning and ask to accept for a WebSocket connection like it does with a webpage, it will just fail with an error in the console and nothing else.
P.S. - You should not hard code the client id in web apps, this is because client ids must be unique across ALL clients, so hardcoding it means that everybody that visits the page will use the same client id and each new connection will kick off the last one (and probably end up in a reconnect fight)
If you check the logs of EMQX, maybe you can get more helpful information.
The following are possible reasons for common TLS connection failures.
First of all, as mentioned in the previous answer, your certificate may have a domain name or IP address set as CN or SAN when it is issued, but the address you specified when connecting does not match the values of the CN and SAN fields.
In this case, the TLS client will think that the server you are connecting to may not be what you really expect, so it will refuse the connection.
We have three ways to solve it:
Turn off the verification of the peer certificate, if your client has this option. However, we do not recommend this as it increases the security risk.
Reissue a certificate that matches your server address
Set the SNI field (full name Server Name Indication) when the client connects, so that TLS will check whether the SNI matches the CN and SAN fields of the certificate, instead of your actual connection address.
The second possible reason is that your certificate path is incomplete, such as the lack of intermediate certificates, or the client does not specify a trusted root certificate, its keyword in the EMQX log is unknown_ca.
For more TLS error reasons, you can refer to SSL Connection Error.
In a browser environment, you should use a server certificate issued by a CA Signed than a self-signed certificate.
Self-Signed SSL Vs Trusted CA Signed SSL Certificate， see the https://cheapsslsecurity.com/blog/self-signed-ssl-versus-trusted-ca-signed-ssl-certificate/
In application gateway "Backend certificate is invalid", Do really require by app gateway to monitored the validity of backend server certificate?
As because we have seen due to this human error can be encounter, whereas application owner and Azure administrator should be aware of the working flow of the application. But although the certificate is invalid to-and-fro communication would be secure, hence its worthless of mentioning "HTTPS connection won't be secure unless the server's TLS/SSL certificate is valid" in Azure portal.
However now a days every organization looking for cost saving, whereas Administrators are working in shared model and if any production application missed to update certificate in-between, can cause the business loss.
Rather MS has to introduce server certificate profile in http setting, which accepts the default certificate no matter valid or invalid and monitoring only the secure connection for end-to-end encryption.
https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-backend-health-troubleshooting
Currently, for the TLS connection to work in Application gateway, you need to ensure that the TLS/SSL certificate meets the following conditions:
That the current date and time is within the "Valid from" and "Valid
to" date range on the certificate.
That the certificate's "Common Name" (CN) matches the host header in the request. For example, if the client is making a request to https://www.contoso.com/, then the CN must be www.contoso.com.
Refer : https://learn.microsoft.com/en-us/azure/application-gateway/ssl-overview
If the Trusted Root Certificate uploaded is expired or backend server certificate’s Common Name (CN) does not match with the Hostname entered in HTTP Settings, the probe (default or custom) will start marking the backend servers as Unhealthy so that the requests won’t be routed to them.
There is no other way available to get this working at the moment. If you wish you may leave your feedback in the below forum requesting the desired feature. All the feedback you share in these forums will be monitored and reviewed by the Microsoft engineering teams responsible for building Azure.
https://feedback.azure.com/d365community/forum/8ae9bf04-8326-ec11-b6e6-000d3a4f0789
I have configured mutual authentication on an Azure Application Gateway. Currently all client certificates issued by the intermediate CA (as configured on SSL profile) are accepted, but I only want a specific certificate to be granted access, ideally based on the subject of the client certificate. Making changes to the CA that issues the client certificate is not feasible in my case.
Options explored:
Use leaf certificate when configuring SSL profile: app gateway seems to ignore the leaf certificate; all client certificates issued by the intermediate CA are accepted.
Configure a rewrite rule action to pass a server variable (e.g. client_certificate_subject) to backend in a custom request header. This would require changing the backend to interpret the request header, which I’m trying to avoid.
Configure a rewrite rule condition to check server variable (e.g. client_certificate_subject) and conditionally take some action. Ideally the action should set the HTTP response code (without forwarding the request to backend) or rewrite to an error page generated by the app gateway (e.g. HTTP 401 unauthorized / 403 forbidden). Can this be done somehow?
WAF rules don’t seem like a viable option as they don’t have access to server variables
Hoping to find a way of configuring this requirement on the app gateway. Thanks.
I understand that you want to be able to allow specific certificates only based on their subject names etc., to be granted access by the Application Gateway.
You can't use a rewrite rule because in order to "get to" a rule in the first place you have to get through the listener and you can't get through the listener if you can't authenticate with mutual authentication.
At this point, the best way to avoid people from accessing App GW would be to not give the Leaf certificate so they cannot access the same.
Also please note that Application Gateway Mutual Authentication is in preview right now and therefore, it is intended for "Evaluation" and testing, and not production currently. Once it is GA, there will be options to have revocation lists and checks.
Hope this helps. Please do let us know if you have further questions. Thank you!
I am trying to setup a Mosca server with SSL/TLS encryption.
Looking at the Mosca wiki at the page https://github.com/mcollina/mosca/wiki/TLS-SSL-Configuration suggests that we will require a private key and a certificate for the broker.
While that page is silent about the the configuration on the client side for the mqtt over SSL/TLS, I found an article by Mattino Collina himself on SSL/TLS configuration on the client side. Here http://www.hivemq.com/blog/mqtt-client-library-mqtt-js
This article states that for mqtts we need to provide a key and a certificate on the client side too. Should they be the same key and certificate that we provided while setting up the broker or different for every client that we connect to the broker?
Are these keys and certificates a way of authenticating the client for the broker?
How many certificates and keys depends on exactly what you are trying to achieve.
If you just need a secure connection then you only need a certificate and private key on the broker. (you may need to supply the CA certificate to the client depending on if you sign your own certificates or if you use certificates signed by recognised public CA).
If you want to uniquely identify the client via SSL then the client will also require it's own unique certificate and matching private key. These will be different from the brokers certificate/key pair, but probably signed by the same CA.
I have an asp.net mvc web app that has been running in production for about 4 years. Suddenly since about a week ago, I am getting this error being returned for all calls to 3rd-party secure API's:
System.Net.WebException: The underlying connection was closed: Could
not establish trust relationship for the SSL/TLS secure channel. --->
System.Security.Authentication.AuthenticationException: The remote
certificate is invalid according to the validation procedure.
This is for calls to SendGrid for sending emails, calls to Azure Blob Storage for uploading of documents, calls to Connect.io for logging.
I have managed to resolve the Azure Blob Storage problem temporarily by changing the connection string to use http instead of https.
Clearly something has broken on my app server, and I have no idea where to start looking.
Please help.
Edit:
Turns out I was using a sample library provided by one of my (lesser-used) 3rd party API's, and this library had an override of
System.Net.ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors)
which had it's own logic about what constitutes a valid certificate!!! AARGH!
This part become key information for your problem:
I am getting this error being returned for all calls to 3rd-party
secure API's
According to MSDN blog:
This error message is caused because the process is not being able to
validate the Server Certificate supplied by the Server during an HTTPS
(SSL) request. The very first troubleshooting step should be to see
if the server supplied certificate and every certificate in the chain
is trouble free.
Because it seems that one or more third party certificates are rejected, you may configure Trusted Roots part of your certificate trust lists to include all required third party CA as part of chain to work with secure APIs from trusted sources, including reissued certificates if any.
Further details: https://technet.microsoft.com/en-us/library/dn265983.aspx
NB (Optional):
As temporary measure, you can implement this certificate validation handler in WebRole.cs until all related third-party certificates has reissued (remember this setting will trust all issued certificates, hence it's not recommended for long term usage):
System.Net.ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;
Additional reference: http://robertgreiner.com/2013/03/could-not-establish-trust-relationship-for-the-ssl-tls-secure-channel/
Similar thing happened in our system. Our problem was TLS version. The SSL offload appliance was configured to accept only TLS 1.2. One week ago this configuration accepted all TLS versions 1.0 to 1.2.
We had to reconfigure .NET's SecurityProtocol settings like:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls12;
You can use this site to test which TLS version you are using: https://www.ssllabs.com/ssltest/index.html
Try to get some information about the certificate of the servers and see if you need to install any specific certs.
The server(s) may had a cert signed by a 3rd party CA which you hadn't trusted yet. The solution is to add that CA to the Trusted Root CA list.