I am receiving the below error when I try to enter my domain, username and password during the iOS enrollment process. I have everything pointing to the domain name of the server, not the IP address. I don't know why its istrying to use the IP to enroll the device as everything is changed to domain names in the config files.
Does anybody have ideas?
Thank you!
[2016-04-15 10:46:27,836] ERROR {org.wso2.carbon.device.mgt.ios.util.OAuthUtils}-
Error occurred while sending 'Post' request due to failure of server connectionjavax.net.ssl.SSLException:
hostname in certificate didn't match: <IP> != <hostname>
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:227)
at org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:147)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
When creating SSL certificate then you need to have the domain name as the common name. Also make sure you change config.json files accordingly with the domain name specially when it comes to EMM Jaggeryapps. Also in cdm-config.xml.
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'm trying to run OpenIddict in Docker together with an Api, the Api communicates with the OppenIddict application through a defined link in docker-compose (api -> login). I have a frontend application running outside of Docker accessing the Api and Login over localhost-addresses. Everything works fine until the point where the Api communicates with the Login application using the linked address (login), the problem then is that the issuer of the token doesn't match.
The issuer is in this case http://localhost:4000 and it's expecting http://login when OpenIddict is validating the token.
I've tried to change the issuer in Startup and the OpenIddictServerBuilder, the problem then is that it changes the base address used in the discovery document resulting in the frontend trying to connect to http://login.
One potential solution to this is to change the hosts file and set a network redirect (redirecting login to 127.0.1.1 and setting the network redirect to use localhost:4000), but this feels like a too complex solution.
I've had similar issues with IdentityServer4, but there you can change the issuer without affecting the base address.
Hope that I explain the issue well enough, any ideas is really appreciated!
Finally figured it out, you can specify a list of valid issuers during the configuration of the OpenIddict server in Startup. Here I can say that http://localhost:4000 is a valid issuer and therefore the token will be valid when the Api validates it even though it is communicating using a different address. I did it like this if it helps anyone in the future:
services.AddOpenIddict()
.AddCore()
.AddServer(builder =>
{
builder.Configure(options =>
{
options.TokenValidationParameters.ValidIssuers = new List<string>
{
"http://localhost:4000/",
};
});
});
I am trying to verify the server domain for Apple Pay. I have placed apple-developer-merchantid-domain-association.txt as per the Apple pay instruction and I can access this file with that URL as well.
But when i am going to verify the domain it shows me following Error:
Domain verification failed. Unable to access verification file on server. Confirm that the file is in the correct location, proxies and redirects are not enabled, and the documented Apple Domain Verification IP addresses can access your server.
I don't know what's wrong in configuration.
By the way, This Website is hosted on AWS behind Load balancer.
Wo Got solution of it:
It sounds weird but it worked. Earlier we were using the amazon provided SSL from ACM. And Apple was not able to verify the domain because of SSL related issue. After that we taken new SSL from GoDaddy and setting up on server and it solved our issue.
Seems like Apple was not able to verify domain from the free SSL provided by the AWS.
I have an iOS client app which connects to a server using HTTPS.
I've added code in the client to verify the identify of the server.
How can a tester testing this feature test that it is now secure, how can they for example create a MITM situation and check that the client rejects connects etc.?
I've tried googling for how to do this but haven't had much luck.
Can it be done using tools like Charles and proxies etc. or is messing around with a wireless router and having detailed knowledge necessary?
This might be over simplification for your solution, but concepts might help.
A web browsers extracts the name of hosts from embedded certificate and do a comparison of host name that we're trying to connect with. If validation fails, we usually see a security warning. For ex: we can connect with facebook by either typing https://www.facebook.com or by typing https://173.252.100.16/. When we choose second option, we get a security warning.
Your program must be using SSL client socket to connect with HTTPS server. The socket must be having capability to extract the hostname from the embedded certificate. Once you get that, compare that with valid HOST NAME that your program is trying to connect with. If it matches, let request proceed, If not, abandon that session.
To re-create MITM, your web server can use a self signed certificate that can be issue to whatever host name you want, but the IP of server could be 127.0.0.1 (for example). Since there is a mismatch between the host name and actual IP, we can probably simulate the MITM situation.
I'm assuming that digital certificate can't be forged in this case.