I'm trying to create a https endpoint on my azure application, but I've run into a problem.
I have a CNAME record (in our local ISP's Name Server), like MyApp.MyDomain.com, which maps to MyApp.cloudapp.net.
Microsoft documentation tells me that I need to get a Certificate Signing Request (CSR) for MyApp.MyDomain.com. However, the only place this exists is in the local ISP's name server, and they tell me that they can't create this CSR since they don't host that domain. This doesn't make sense to me, since nobody "hosts" that domain, it's just a CNAME.
So I don't know who can create that CSR. Is it something I can do locally (i.e. on an IIS that is unrelated to that domain), or does it need to be done on Azure's / local ISP's server?
You can do this locally and you'll send it to the company you buy the certificate from (let's say Comodo). Once they're done, they'll send the response and you'll need to upload it in IIS (under Server Certificates, Complete Certificate Request).
The result will be that you'll have a PFX file (a file with public and private key). Once you have this file you'll need to upload it in the Windows Azure Portal, and in your WebRole you'll need to fill in the thumbprint of that certificate.
Once you've done all this and you deployed the application, you'll be able to access the website through HTTPS and you'll see that the certificate will be used correctly.
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 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?
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 want to migrate an existing On Premise WCF service to Windows azure without asking clients to change anything in thier application like endpoint URL, certificate etc.
PLease let me know if this can be done?
In principal - yes.
The Endpoint Url is dependant on you controlling the domain and forwarding the URL over to Azure (for us, we use a CNAME redirect to the Azure URL). More details here.
For the certificate, as long as you've got an exportable version of the certificate with a Private Key, it should be a matter of uploading the certificate to the server that matches the endpoint URL. More details here.
So, all in all (with these changes in place) it's just a matter of uploading the certificate, redirecting to over to Azure and then letting DNS do its thing. If in doubt, certificates are buttons to purchase, so use that for testing purposes to prove the concept.
Azure Websites now supports SSL and allows you to upload a certificate. I have a GoDaddy certificate that I have uploaded and although this works fine for 80% of users it seems that Windows XP users browsing the site in Internet Explorer are given the following error:
There is a problem with this website's security certificate.
On further investigation it seems like I may need to provide an intermediate certificate but I can not find how to supply a Godaddy intermediate certificate (I have one) for my Azure Website.
Can anyone tell me if there is a solution to the intermediate certificate issue?
I followed the following step process when I was setting up SSL in Azure using GoDaddy as CA. (Notice the highlighted line below that might be your key):
Create a Certificate Signing Request (CSR) on the web server (local IIS, not Azure)
Send CSR to CA (Certificate Authority – GoDaddy) and specify alternative domain names (if you've paid for that possibility)
Download certificate from CA
Import certificate to web server (local IIS, not Azure)
Import the intermediate certificates from CA into local computer (where you have IIS)
Export the certificate as PFX file from IIS and give it a password
Import PFX file into Azure together with password
Bind configured domain names to the certificate in Azure
There are a few different ways to create the CSR file. I used IIS Manager on my local developer computer.
You can read an extended version of the list here where all the steps are more thoroughly explained.
Had a reply on twitter from Microsoft, the reply they give is as follows: "this is a known issue. Not an oversite but rather a bug... Check the MSDN support forum" I checked my post on MSDN forums and the reply they left there is "We will have this support soon".