I installed a GoDaddy issued certificate and getting this error below while calling https with 8181 port. It worked fine with HTTP.
The certificate for this server is invalid. You might be connecting to a server that is pretending to be “my.ip.” which could put your confidential information at risk."
Did restkit error out because i am using IP instead of valid domain name?
If you are connecting via typing https://your.ip:8181/ in your browser, that is the issue.
SSL/TLS certificate for web site contains domain name for which it is issued, and it should match the name typed in address bar.
Related
I have an iOS App that I am compiling in Xcode 11.2.1. I am running MacOS Catalina 10.15.6.
My app consumes a Web Service that works fine when called unsecured over http.
I am now busy implementing security and we have bought a wildcard certificate from digicert and installed it on our API server. I have run the SSLLabs Server Security Test and the server gets an A-grading so all seems fine. We have updated the Android version of the app to use https instead of http and it is working fine. When I access the https endpoints from a browser it works fine and I don't get any security warnings or errors.
However, if I change from http to https and build and run the iOS App I get TLS errors. (I am calling the web service using URLSession and I am using Swift). I am putting a relevant section of the error log below to show the -9802 and -1200 errors I am getting.
ATS failed system trust
Connection 1: system TLS Trust evaluation failed(-9802)
Connection 1: TLS Trust encountered error 3:-9802
Connection 1: encountered error(3:-9802)
...
finished with error [-1200] Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." UserInfo={NSURLErrorFailingURLPeerTrustErrorKey=<SecTrustRef: 0x600001082b50>, NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9802, NSErrorPeerCertificateChainKey=(
I found https://support.apple.com/en-us/HT210176 and I was wondering if it is perhaps an issue that the "Subject Alternative Name" in our cert is our wildcard domain "*.domain.com" whereas the url we are connecting to is "myapi.domain.com". Could that be the problem? What else could I be missing?
In case someone else stumbles upon this...we ended up adding the specific subdomain we're calling in the API from our app to the "Subject Alternative Names" field on the certificate. So instead of just having "*.mydomain.com" in the Subject Alternative Names, we included both "myapi.domain.com *.mydomain.com". After we deployed this certificate to the server and we again tried calling myapi.domain.com from our app, the error went away and everything worked. (For those worried that this requires the purchase of a new certificate...it doesn't. It's quite possible to get such a copy of your certificate without having to buy a different one. Just check the documentation of the certificate issuer you are using.)
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 dont know why its trying to use the IP to enroll the device as everything is changed to domain names in the config files.
Any ideas?
Thanks
[2016-02-24 15:15:23,556] ERROR
{org.wso2.carbon.device.mgt.ios.util.OAuthUtils} - Error occurred
while sending 'Post' request due to failure of server connection
javax.net.ssl.SSLException: hostname in certificate didn't match: !=
I have an application (an installation of Discourse) that I'm trying to deploy. However, the email server that it is pointed at has a self-signed ssl cert for SMTP.
Is there a workaround for this? Or do I need to find a way to send mail using a "valid" SSL cert?
Few things actually care that deeply about a proper cert for SMTP. Mostly user agents.
If the cert is a problem you won't get timeouts, you'll get validation errors. I suspect what's happening is that you're trying to connect over the SMTPS port which isn't listening or exposed by the firewall.
Try using SMTP+STARTTLS. That negotiates TLS over port 25 or 587 instead of trying to connect directly to 465.
I am running into a strange error in my iOS client when attempting to connect to an f5 BigIP server via 2-way SSL (HTTPS) - the client is able to verify the server via its certificate only when the server is not requiring a client certificate during the SSL negotiation. The certificate for the Root CA that signed the server and my client certificates is already in my trusted anchor certs list.
Here are the steps in each test that I have attempted, and their SSL negotiation outcomes:
Server does NOT require client cert, client verifies server cert (1-way ssl: client -> server)
Client verifies server certificate (pass)
Client provides its cert to server (unchecked - not required by server)
Connection established, server allows client access
Server requires client cert, client verifies server cert (2-way SSL: client <-> server)
Client verifies server cert (FAIL!!)
Nothing else happens
Server requires client cert, client accepts any server as trusted (1-way SSL: client <- server)
Client does NOT verify server cert (setAllowsAnyHTTPSCertificate:YES - done for testing purposes only)
Client provides its cert to server (pass)
Connection established, server allows client access
Between cases 1 and 2, only the server is changed to require client certs (thereby enabling 2-way SSL), while the client verifies the server cert in both cases. Between cases 2 and 3, the client is changed to accept all server certs while the server requires a client certificate in both cases.
So it appears that I am only able to achieve 1-way SSL in either direction but not 2-way SSL. This is strange because as the initial step where the client verifies the server should happen before the server asks for a client certificate, and therefore produce the same result each time. The error I get from test case 2 is as follows:
The certificate for this server is invalid. You might be connecting to
a server that is pretending to be “server.myexample.com” which could
put your confidential information at risk. Error occurred while
fetching https://server.myexample.com/service: Error
Domain=NSURLErrorDomain Code=-1202 "The certificate for this server is
invalid. You might be connecting to a server that is pretending to be
“server.myexample.com” which could put your confidential information
at risk.
I get additional messages with the same info but specifying the errors: NSErrorFailingURLStringKey, NSErrorFailingURLKey, NSUnderlyingError, and NSURLErrorFailingURLPeerTrustErrorKey.
I don't believe I need a different server certificate for 2-way vs 1-way SSL, or do I?
Thanks in advance!
The problem was that I had the client request in an iRule on the f5 server. I removed this part of the iRule and added the request into the client SSL profile. This appears to work with the iOS client, meaning there is probably something strange with the iOS code since all browsers I have tested work either way I make the request (either iRule or client SSL profile). The iOS app only works with making the request in the client SSL profile.
I was using iOS to connect to a server using a certificate whose CN (commonname) and FQDN (fully qualified domain name) is server.myexample.com. The server certificate was signed by my own Root CA (whose certificate I added to my anchor certs via SecTrustSetAnchorCertificates and verified via the method described here using NSURLAuthenticationChallenge).
With my iOS client, I was attempting to connect my REST service located at: server.myexample.com/Path1/service1, but I kept receiving the following error:
The certificate for this server is invalid. You might be connecting to a server
that is pretending to be “server.myexample.com” which could put your confidential
information at risk.
Error occurred while fetching https://server.myexample.com/Path1/service1: Error
Domain=NSURLErrorDomain Code=-1202 "The certificate for this server is invalid.
You might be connecting to a server that is pretending to be “server.myexample.com”
which could put your confidential information at risk."
I get additional messages with the same info but specifying the errors: NSErrorFailingURLStringKey and NSURLErrorFailingURLPeerTrustErrorKey.
I found that I could also call the service with server.myexample.com/service1 and removed Path1 from my request URL, and the server certificate verification worked correctly. Why is this? I was under the impression that the server only needed 1 certificate, meaning any services it hosts would also be using that same certificate. Maybe you need a separate server certificate per path? I was not aware the paths after the server ip address/domain needed to have their own certificate.
To summarize:
iOS client app with Root CA certificate in the anchor certs
Server server1's certificate signed by Root CA has a CN of server.myexample.com and whose FQDN is https://server.myexample.com.
Server server.myexample.com hosts service1 which can be accessed by web browser via:
https://server.myexample.com/service1 (passes iOS client's authentication of server)
https://server.myexample.com/Path1/service1 (FAILS iOS client's authentication of server)
CA and server certificates were created via OpenSSL
Thanks in advance!