I am tryin to create a Google Managed SSL Certificate for my compute engine instance. However, I am required to enter a domain. The issue is, I do not have a domain associated with my instance, I only have its external ip address.
How can I use the ip address of my instance for the certificate, or how do I associate it with a domain?
You might be confusing what Google is asking for.
In order to create an SSL certificate, you must own / manage /control a domain name.
Next, in order to use the SSL certificate that Google created (or by other means such as Let's Encrypt), you map the Google Service, such as a load balancer, to a backend such as Google Compute Engine VM instances.
If your goal is to create an SSL certificate using an IP address - you cannot. SSL certificates require a domain name. There are exceptions to this, such as using a machine name to create a self signed certificate, but this does not apply to your situation.
Another important item. Once you create a Google Managed SSL certificate, you cannot use it on your VM instance. You can only use it for Google managed services such as Load Balancer. The Load Balancer will then sit in front of your VM instance.
If your goal is to create an SSL certificate that you can install on your VM instance, look into Let's Encrypt. Let's Encrypt is simple to work with and their certificates are free. You will still need to own a domain name, but you will be able to control where it is installed.
Once you install a Let's Encrypt SSL certificate, you modify the DNS servers that your domain registrar setup to point your domain name to an IP address.
Related
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?
Microsoft docs say to use something like clustername.eastus.cloudapp.azure.com, but what about custom DNS for the cluster?
Will the certificate properly validate or should the custom DNS (i.e. clustername.domain.com) be used?
The dns provided by the docs is just an example, I don't think you will be able to register a certificate against a domain you don't own like .azure.com.
In this case, you will register a certificate against a domain you own, and you either:
Register a CNAME record on your damain to redirect to the cluster domain clustername.eastus.cloudapp.azure.com or
Configure the DNS A Record to point to you cluster Load Balancer IP
In the demo, the Commom Name is just used to identify the certificate installed in the node(vm) certificate store.
The following links describes the use of certificates in more details:
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-creation-via-portal
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security-update-certs-azure
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-windows-cluster-x509-security
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.
My main site https://example.com has an SSL cert, no problem.
Now, I have developped a related application, that is hosted on a completely different server, and under : app.example.com. It has a dedicated IP.
The app uses websockets and needs SSL to function properly acros all devices. But I'm having trouble finding out how to register a new certificate for a subdomain... What's the strategy here? Should I have a wildcard cert on the main server, and somehow redirect from there? In that case, the app server wouldn't have access to the cert, and I wouldn't be able to create my secure socket connection, right?
The certificate has to be installed where the server which provides content using this certificate. This means
That the certificate for the subdomain has to be used on all servers which serve the subdomain, i.e. your websocket server.
And nowhere else, i.e. it is not needed at the main domain just to provide a redirect from the main domain away.
You are free to use any certificate which matches the subdomain, that is it can be a wildcard certificate but can also be specific for only this domain.
You can go for a wild card certificate and bind it to all the URL's who share the same domain. But keep in mind, the wildcard certificates (irrespective of any brands) supports unlimited first level sub domains .
Wild card certificates can be installed on any server where the FQDN is hosted. In situations where the the sub domains are hosted on multiple servers, the wildcard certificate will work for all of them.
I've asked my provider for a SSL certificate. They said the CSR must be generated from a host having the ip address which blongs to the certificate. Otherwise it will not be vaild later.
As far as I know one can only assign a CNAME to a load balancer and it is not possible to generate the CSR on the load balancer. Apart from that the lb ip might change. So do you get your valid certificates?
Regards,
Jim
You don't have to generate the CSR on the load balancer. You only have to generate it with a name consisting of the required domain name. You can do that anywhere.
Jim, I had the very same question as you. This is my first foray into the realm of multi-server deployments with SSL.
I found this: http://www.martfox.com/customer/knowledgebase/140/Why-a-SSL-Requires-Dedicated-IP.html
It looks like it is commonly said that you must have a static IP address to run ssl, but it really looks like you don't need a Static IP as much as an IP that you are the only one using at the time. The IP address is not needed when signing a certificate, or creating a signing request. It is not attached to your keys in any way, so you change Static IP addresses or even move hosting providers without reissuing your SSL cert.
It appears that the limitation is because VHOSTS and other server aliasing methods don't have access to the HTTP request string before they have to connect the SSL layer, so they aren't able to route it like they do unauthenticated requests.