I have a backend application that creates temporary servers via the Digital Ocean API. There is a browser frontend that needs to send AJAX requests to the servers.
Let's Encrypt isn't an option because they require a domain name, like most SSL certificate providers. I could create my own self-signed certificate, but then the browser would not trust it.
Although I could probably assign a subdomain to each temporary server, it may take some time for the DNS to recognize the assignment.
Is there a solution for secure and browser-accepted communication to my temporary servers?
Related
I'm using a React frontend application on a domain with a valid SSL certificate, which makes calls to a Django backend application on a VPS (Ubuntu 20.04, apache2), which doesn't have a domain name registered (instead the calls are being made using the IP of the server). The server doesn't yet have a valid SSL certificate which prevents the React app from receiving the resources. Self-signed won't work since it's then not valid in the browser (I might be wrong here).
Do I also need to register a domain name for the backend API server for the SSL certificate to be valid or can I just buy an SSL certificate and work from there?
To even get an SSL certificate back from the vendor, you need a fqdn (fully qualified domain name). That information is used to sign and create the certificate request. Your webserver won't even properly encrypt until you have valid signed certificate for the server in question. You can expand the number of hosts that a certificate will serve by buying a wildcard certificate (*.example.com vs specifichost.example.com)
If your back end server is on some cloud or hosted service, you can use self signed certificates but you would have to disable "strictness" in your front end. If you're at any time performing financial transactions this is not advisable.
If you're making axios calls, here's a pretty good article on disabling https strictness (https://github.com/axios/axios/issues/535).
Your vendor for the VPS might have some helpful information on how to harden up the server.
If this is not how you'll be doing this in production and the setup you describe is for testing only, then probably you want to use the environment to set a variable indicating 'strict' or 'test' and switch your calls accordingly. That way, a relaxed setup will work in test or in your sanbox, but production would use a properly configured host with a valid certificate.
I'm building a website with separated backend / frontend. For now this website is hosted on my Kubernetes cluster at home. There is one pod for the frontend and another for the backend.
Theses pods are accessible via Traefic. I have internal DNS name (ie backend.home.local and frontend.home.local) to access it. I have generated a self-signed CA that handle the SSL on my .home.local private domain so I can reach them in my private network from my computer which have registered my private CA.
My frontend communicates with my backend also via HTTPS using the same url ( in .home.local). My frontend knows the CA (I proceeded like here).
I also have an external domain name pointing on my frontend. I can access on it via HTTPS without trouble outside and inside my network.
Ok so far so good. My issue is that when I access to my frontend via my external domain name, my frontend succeed to communicate with the backend when I'm using a computer which have registered my private CA but it fails with a err_cert_authority_invalid when I'm using a computer without my CA.
I understand by that the end user have to have the CA of all resources of the website, else the browser throw an error, even if the frontend initiate an other SSL connection with the backend with its own the CA.
I also tries to deactivate https between the frontend and the backend but this time I have mixed contents error ... not better.
Do I inevitably have to have a backend accessible from outside with a proper let's encrypt certificate ? I would prefer have a backend not accessible via outside but I don't know if I can do that properly.
I hope this post is not too messy.
Have a good day.
Do I inevitably have to have a backend accessible from outside with a proper let's encrypt certificate ?
Yes, that is the case. This does not necessarily mean you have to change your backend service, you can do SSL termination for your backend through traefik. Setting up Let's Encrypt through traefik is fully automated process, it should be fairly easy.
Think about it - HTTPS is not just a "nice to have" feature, it is essential for security. All communication over public networks should only be done securely.
I have a website that run under a H2O Proxy, let's call it A server. The backend is WordPress site running with EasyEngine script, let's call it B server.
Now it running like this:
User --(Let's Encrypt SSL)--> A (H2O Proxy) --(self-signed SSL)--> B (nginx backend).
I wonder if attackers know my backend's IP address, so can he decrypt or do harmful thing or see what user send to proxy? And how to setup a better strategy?
I have thought to setup Let's Encrypt SSL from A server to B server too. But I think the problem will occur when Let's Encrypt can only renew certificate on A server because the domain is pointing to A's IP address. And the backend (B server) can't renew it.
Found this answer but I don't really know how to do it: https://serverfault.com/a/735977.
It sounds like what you're trying to do is to put LetsEncrypt into as many places as possible, possibly facing the issues of not having the desired Fully-Qualified-Domain-Name for the applicable backend on the backend itself in order to get the certificate, especially for automated renewal.
But the whole and only purpose of LetsEncrypt is that it gives you certificates that would expectedly be recognised by all the major browsers, such that the users would not have to manually verify and install your certificate into their respective cacert.pem.
But if you just need a secure connection between your own backend and front-end server, then you're not facing the same issue; as such, using LetsEncrypt provides little, if any, extra protections. What you have to do is use something like proxy_ssl_trusted_certificate, together with proxy_ssl_verify, both on the front-end, to pin the backend's certificate and/or certificate authority on the front-end, which will be an order of magnitude more secure (due to the pinning) than using LetsEncrypt on the backend.
I am developing an app to run in Cloud Foundry.
The app makes constant connections to a web service using https protocol.
The web service uses a pair of self-signed certificate created by openssl.
As there is no DNS setup, I am using IP address as the Common Name(CN) in the ssl certificate.
However, the web service IP address varies from time to time. The ssl certificate has to be re-generated each time.
In order for the app to connect, it needs to trust the SSL certificate so I have been packaging the public key for the web service’s SSL cert as a file with my app.
The problem is that I have to re-upload the app to Cloud Foundry once the public key of the SSL cert changes.
Here are some possible solutions:
Register a host name in DNS. In that case, the certificate is only bound to host name. (Might not be possible cos of the budget. )
Create a private CA and issue certificates from the CA, then install the CA as the trusted CA on the client. It is feasible and a common way for internal services. However, what if the app is pushed to the CF? How can we configure the node for the certs?
Disable the SSL server authentication. Not sure whether it would put the app at risk if the authentication is skipped. For the time being, the app pulls data from the web service.
I've been thinking of keeping the public key in the database. In that case, I don't need to re-upload the app to make it take effect. But I am not sure whether it is a safe way.
Question
I am seeking for a common and safe way to keep the SSL server cert in a Cloud Foundry env. Are any of the above solutions viable? If not, is there any other CF preferred ways?
Thank you
This is a bit old, but in case this helps...
Did you try to generate your server SSL certificate with whatever hostname (even "localhost"). As you are uploading this certificate in your application (i.e. to "blindly" trust it), I think that it could work and this would avoid dependencies with your IP address.
I am having a bit of trouble understanding how many ssl certificates I should get under specific conditions:
I have two pages the user is supposed to use (index and main) and all other scripts users don't access in the front end (e.g. uploadFile.php).
I have socket.io implemented in port x which I want to run over https protocol.
How many ssl certificates should I get under these conditions to assure secure data traffic? (is the data from all other php scripts still secure if index and main have ssl?)
SSL cert is issued for a specific DNS name. So if you run your PHP and Socket.io applications on the same domain, one cert is surely enough to secure both.
If you run your app on two different domains, you need to (a) use two separate regular certificates, or (b) have one SAN certificate (it secures multiple DNS names).
Also there is a wildcard certificate, it secures all direct subdomains of specified domain (*.some-site.com). It can be combined with SAN feature, so it can secure base domain some-site.com and direct subdomains as well.
IF your website is accessed via different website on https , then your website and the website through which its accessed needs to have their separate SSL certificate.
If your website does not have an ssl certificate , the connection will be dropped when your website link is accessed via other website.