I'm getting crazy with SSL certificates. After trying from lots of different providers I finally got one using SSL for free.
But there's one thing that I haven't understood yet.
Do I have to upload my certificate on my Domain provider (such as Register.it) or on my Host service (such as 000webhost or InfinityFree)?
The problem is that 000webhost offers a better service but not the possibility to upload an SSL certificate on a free plan, while InfinityFree (which offers a worse service) does.
I have the possibility to upload my certificate on the Domain provider (Register.it), but I can't understand if it works or it is overridden by InfinityFree one, and I have difficulties in trying switching from Host to Host because of the really slow DNS propagation.
Sorry if I made confusion, but it was to explain better my situation... My question remains one: Do I have to upload my certificate on my Domain provider or on my Host service?
You need to upload ssl certificate to your hosting. SSL for free is a Let's Encrypt certificate.
You can check which provider ssl running on your domain.
Step:
Tab your browser green lock icon then details
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 was studying Websockets (wss) and I am a little confused about their use of SSL. I hope some of you will be able to clarify some things that cause the most confusion to me.
Use scenario
Let's say I have an HTTPS secured website with a certificate signed by CA. I would like to communicate with a custom app in real-time (using the WebSockets) running on an external server that is not using the same domain (the site is for example www.mysite.com and the server is www.notmysite.com).
The confusion part
When the WebSocket client (wss) is connecting to the remote server, what SSL certificate does it use? Is it of the origin website, or of the server it is trying to connect to?
Given the scenario, can a connection be established with a single-domain SSL certificate - only for the website (www.mysite.com) where we know the private key and therefore we should be able to decrypt the encrypted data?
If question no. 2 is false, would multi-domain certificate containing both urls fix the problem?
The background story
I was trying to make a WebSocket server in .NET C#. I managed to get it working with HTTP however when I tried the code on HTTPS secured website I was presented with an encrypted text I could not really work with. That is why I bought an SSL certificate and put it on the website thinking that if I have the private key I can decrypt the data and communicate with the client (basically question no.2). Though I was only presented with different errors regarding cryptography. I was trying to figure this out for over a week and my progress and frustration can be seen in my other questions such as:
C# RSA decrypt parameter is incorrect and
AuthenticateAsServer() error
Then I figured out I may need to look at it from a different point and that's when I came up with this theory. I hope some of you will be able to end my suffering with an explanation of why what I did was wrong. I appreciate any help. Thank you very much.
I am not 100% sure if the multi-domain SSL certificate solved this issue since I combined it with using a premade library (WebsocketsSharp) which along with the new multi-domain certificate works perfectly. In my opinion, the multi-domain certificate is needed if you want to communicate between two different servers (either website and server or two servers).
I hope I will save some future headaches.
I'm looking at hardening LDAP on my domain controller (DC). To do this I need to import a security certificate to the DC.
I don't want to self sign as I've been told it is not best practice and the service I wish to integrate with LDAPS (Mimecast) does not recommend self signing.
I've created my certificate request, based upon the domain's fqdn. e.g. mydomain.local
What I'm not sure about now is where I can get a certificate based on that request.
I'm familiar with SSL for HTTPS. That process makes sense to me, the certification authority checks that I own the domain and provides a certificate that I can then install on my web server.
Will 3rd party SSL providers let me configure a certificate with the common name "mydomain.local"?
Or am I looking in completely the wrong area?
Many thanks in advance for any help that provided.
The type of certificate is exactly the same type of certificate as you would get for securing a website, yes. However, the domain name must be a valid internet domain (not .local)
There is a good walk-through here for Using Let's Encrtypt for Active Directory Domain Controller Certificates, including all the caveats you need to be aware of.
Say, for example, I have an Azure web app named MyApp and is hosted on Azure as MyApp.azurewebsites.net. It's my understanding that there is nothing I need to do to secure the URL with SSL, as it's done, by default, with a single certificate. So I can already have my users access the app via https://MyApp.azurewebsites.net, and it will be secure right out of the box.
However, say I have another URL named www.MyApp.com that I want to point (redirect) to https://MyApp.azurewebsite.net. Do I have to secure www.MyApp.com with a certificate?
Do I have to secure www.MyApp.com with a certificate?
Yes, we could get more detail info from the official document .
To secure your custom domain name with HTTPS, you bind a custom SSL certificate to that custom domain in Azure.
Before binding a custom certificate, we need to do the following:
Configure the custom domain - App Service only allows adding a certificate for a domain name that's already configured in your app. For instructions, see Map a custom domain name to an Azure app.
Scale up to Basic tier or higher App Service plans in lower pricing tiers don't support custom SSL certificates. For instructions, see Scale up an app in Azure.
Get an SSL certificate - If you do not already have one, you need to get one from a trusted certificate authority (CA).
Yes, if you use a custom host name, then you will need to have a certificate for it. There is really no way around this, based on how SSL works.
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.