I'm facing a pain in the ass described as follow:
My iOS app is defined to connect to our company's server, which is a HTTPS one that satisfies all the requirements needed by iOS9's App Transport Security Policy
The app works well with most users
But sometimes there's some users/devices cannot connect due to a -1022 error saying that ATS has rejected our HTTPS server as it's a cleartext server (?!)
After deleting then reinstalling exactly the same build, those users/devices can connect to our server seamlessly
So is there anyone ever encountered the same problem? Can anyone please help troubleshoot the issue?
Note: I strongly against adding my domain the the plist nor using nsallowsarbitraryloads because our server's ssl certificate is strictly valid and satisfy the requirements.
Thanks a lot!
I can think of two scenarios where this could happen:
Your App is trying to access some specific page or link over HTTP (even tho the server supports HTTPS); you could perhaps search for http:// URLs within your code.
There is a specific page or URL on the server that is redirecting clients (such as your App) to HTTP, from HTTPS.
Related
I have a persistent problem with my Heroku app for some users. Since May 2020 I've had 4 users that I know of (presumably there are more) who have been unable to access my app because of the following error:
'Client and server don't support a common SSL protocol version or cipher suite'
I have spoken to Heroku about this, and they have run all tests, checked DNS, ssl certificate etc, and everything looks fine. I have done the same and can see no problem.
2 of the users were able to fix the problem and access the app by altering their DNS settings (one using a VPN, the other had their IT dept change DNS on their machine). The users have not had a similar issue with other sites.
I changed domain name provider to namecheap because they are recommended by heroku because of their dynamic ip, and I thought that might fix the problem, but it doesn't appear to have done so.
This is a very frustrating error, because I don't know what else I can do about it. What is causing this problem, and what can fix it?
I'm trying to upgrade a websocket connection ws:// to wss:// using a nginx reverse proxy https://github.com/nicokaiser/nginx-websocket-proxy/blob/master/simple-wss.conf
but I seem to be having trouble with the certificate part. My server is located on the same network as the client. So Ideally I would want my users to log in to "https://example.com" and then the client makes a connection to "wss://192.168.1.xxx:xxxx".
As of now the browsers are blocking it because of NET::ERR_CERT_COMMON_NAME_INVALID. I don't really know to produce a self signed certificate that the browsers will trust on the local network. Googling only gives me answers on how to do it if my server would be accessed using a domain name but I will always connect to a local network IP. Help is appreciated!
To anyone coming across this I managed to solve it using this post outlining the architecture https://support.plex.tv/articles/206225077-how-to-use-secure-server-connections/
What ended up happening was that we set up a url pointing to a server running nginx which parsed the subdomain and redirected the connection to that url. For example: wss://192-168-1-142.mydomain.com redirects to ws://192.168.1.142 which makes the browser trust the connection
Does this work?
Your post is a year old now and browsers have become stricter since then. Usually, a browser will produce 'mixed content' errors if you access HTTP content from a HTTPS page, and the only way to get round this is to change the site settings to allow insecure content, which is scary for users in the face of a big warning message.
If accessing an HTTPS web address redirects to an HTTP local IP address, won't the browser still complain about mixed content?
I have a similar situation to you. I am writing a Progressive Web Application (PWA) to control network music players on a home network. The players only support HTTP but a PWA requires HTTPS for services workers to work and to allow the app to be 'installed'.
My solution is to run a local server on the home network which can talk to the players over HTTP. Then I can access this server over HTTPS from my browser so that the browser itself is not making any HTTP calls.
This works fine if the server is on localhost because localhost is a special case where security rules are relaxed. But if the server is on another machine, how can I create an SSL certificate since (1) it seems that local IP addresses are not allowed in the Subject Alternative Name (SAN) section of the certificate, and (2) I won't know in advance what the IP address of the server will be.
If your workaround works, then the local server can use HTTP instead so I won't need a certificate. The local server can register itself with a web server, and then the browser can connect over HTTPS to the web server, which would redirect to the IP address of the local server over HTTP.
But does this trick work?
I am using the Let's Encrypt IIS client from https://github.com/Lone-Coder/letsencrypt-win-simple to generate a certificate for a server. Since the certificate is only valid for three months, I want it to auto-renew.
But the server for which I need that auto-renewing certificate is only bound to https:||mysubdomain.mydomain.com:443 and smtp:||mysubdomain.mydomain.com:25.
Both http:||mysubdomain.mydomain.com:80 and ftp:||mysubdomain.mydomain.com:21 point to a different server.
As you may have guessed, the error that is now thrown during the process is "The ACME server was probably unable to reach http:||mysubdomain.mydomain.com:80/.well-known/acme-challenge/abcdefgh...xyz".
It is completely clear to me why, but I can't fix it, because http:||mysubdomain.mydomain.com has to point to the other server. If the ACME server would try https:||mysubdomain.mydomain.com:443/.well-known/acme-challenge/abcdefgh...xyz, but ignore any certificate issue, he would successfully find the challenge.
Is there anything I can do, any feature I have overlooked, that would help me to get automated renewal working?
There are multiple options:
http-01
Redirect http://example.com/.well-known/acme-challenge/* to https://example.com/.well-known/acme-challenge/*, Boulder will happily follow any such redirect and ignore the provided certificate. That's the most simple way if you have access to the other server and can configure that redirect. It's a permanent redirect that you don't have to adjust, it'll be just fine every three months.
The option to use HTTPS directly has been removed due to security issues with some popular server software that uses the first host defined if some other virtual host doesn't define any HTTP host, which might lead to wrong issuances in multi-user environments aka shared hosting.
tls-sni-01
If you want to use just port 443, you can use another challenge type called tls-sni-01. But I think there's no client for Windows available yet that supports that challenge type.
dns-01
If you have control over the DNS via a simple API, you could also use the DNS challenge, it's completely independent of the port you can use.
I have an old apache web server, with some security issues, that running an old application exposed by internet. Before upgrading apache version, I must perform a lot of tests in a dev environment. During this time I would put a reverse proxy (with last apache web server version) in front of this application.
This temporary workaround can resolve some old apache security issues or it is totally useless?
Thanks in advice and I'm sorry for my bad english.
This temporary workaround can resolve some old apache security issues ... ?
Yes, with "can" and "some" emphasized. A reverse proxy handles incoming requests and rewrites them in a canonical form, which is safer for the application server to parse. A reverse proxy can also reject malformed requests so that they never reach the application.
It might not resolve every security issue, but you imagine one that this would resolve. For example, if a specially crafted causes the older version to execute arbitrary code, while the new version would drop the request, then having the reverse proxy would help prevent this bug from affecting the application server.
It's not as much of a defense as using a web application firewall, but it's kind of related.
I'm working on a site that exposes endpoints over HTTP and HTTPS through Azure Web roles.
We've done some updates to the database, and to force the sites to re-populate their cache we've rebooted the roles. Now, however, the SSL endpoints no longer work - connections to the server are broken.
We've tried reimaging the instances, which also didn't help.
Answering my own question to serve as reference for the future:
We'd removed the certificate used for Remote Desktop access to the site.
Interestingly, this caused the SSL side of the site to fail, but only on a reboot.
Our fix was to replace the certificate, then do a full redeploy to staging and a VIP swap.
It does appear that the load balancer is very sensitive to its certificate configuration. I've found before that if there's any issues with any of the certificates in a package that the load balancer just stops working with no error in the log.