This question already has answers here:
Swisscom Cloud SSL certificate
(3 answers)
Closed 6 years ago.
The Swisscom documentation on Routes and Domains acknowledges that
If you use domain forwarding, SSL requests to the root domain may fail if the SSL certificate only matches the subdomain.
However, there seems to be no way to add a custom SSL/TLS certificate to your domain. Am I missing some hidden settings? Other Cloudfoundry providers have special interfaces for installing certificates in their web admin applications. So when trying to use a private domain for a Route to an app there and you access it via HTTPS, as expected, you get an invalid certificate error (because you get served the scapp.io certificate).
So: How do I set up a custom SSL certificate for a private domain in Swisscom’s Cloudfoundry?
SSL certificates from Let’s Encrypt are now available on the Swisscom Application Cloud: SSL Secure Routes
You might want to use Cloudflare that provides such a service.
See also Swisscom Cloud SSL certificate
Swisscom Application Cloud team is aware of this issue.
We are currently busy preparing proper answer to it.
Please expect some communication concerning this subject in the next issue of Application Cloud monthly newsletter.
All registered Application Cloud user should receive it. If you are not yet among them - please sign up!
Related
I'm developing an app for a non-tech client that has outsourced the backend to another developer. We'll be launching the app under 7 different branded app, over a series of weeks. Each app is exactly the same, sans for the domain the API end points are on (IIS hosted).
As part of our security, we validate the SSL certificate when we connect to the API, and ensure the key returned by the API server matches our hardcoded version of it, as to prevent man-in-the-middle attacks to sniff our REST calls. We have this functioning now for the current server (1 of 7 to be rolled out).
We've asked the backend guys to provide the certificates for the remaining 6 sites, so we can deploy the apps with the expected keys. However, they claim that as they will be rolling out the sites individually over the coming weeks, each time they bring a new a new site online, they said they are "updating the SSL certificate" which is required as they are "using SNI on the server, so each time a new site is added, the certificate will change, and the hardcoded validation for the existing sites will break".
Now whilst I'm no dummy, I'm also not a server admin, and only 99.9% sure that the SNI configuration to support another cert on the server, will not have any affect on the current certs already hosted for the existing domains. As a result, I wanted to explicitly confirm that the cert key we're validating as part of the SSL auth, is not going to change with each revision of the SNI config. The backend devs have essentially shut us down claiming we're paranoid, and going "beyond what is required" and to not expect "the same security a the major players offer" (as I mentioned that any decent commercial app validates its connection).
Is anyone able to confirm (or correct) my understanding of SNI as it relates to the certs, primarily that as they bring new sites online, that changes to the SNI have 0 impact on the existing certs for the current sites?
Edit: Whilst the use of multi-domain certs would regenerate the key, we can assume that they could generate/re-issue a multi-domain cert now in advance of the domains coming online. The question of if it's affected by the SNI config remains.
"updating the SSL certificate" which is required as they are "using SNI on the server, so each time a new site is added, the certificate will change, and the hardcoded validation for the existing sites will break".
This is a weird argument. The point of SNI is that they can have multiple sites (domains) on the same IP address where each has its own certificate. If they add a new site only a new certificate for the new domain need to be created and all the other certificates will continue to work: a client using SNI will tell which site it wants to visit and the server then can pick the appropriate certificate. If they instead could not rely on SNI then they would have to use certificates which cover all sites on the same IP address.
So while it can be that they have some process which requires this kind of reissuing certificates it is not a requirement because of use of SNI, but only because they designed their process this way.
I found this example of setting up a service to do SSL termination on a backend service as opposed to on the ingress controller, but I don't see where to specify which certificate to use. I'd like to use a certificate I already have in my Google cloud certificate store. Where do I set that? How does this example work without a certificate?
https://github.com/kubernetes/ingress-gce/blob/master/examples/backside-https/app.yaml
More information about frontend vs backend HTTPS: https://github.com/kubernetes/ingress-gce/blob/master/README.md#frontend-https
If the backend service is using a certificate signed by a public CA, then nothing needs to be done. The GKE ingress is just like any other client to your backend- it knows about various certificate authorities and it can verify that your backend certificate was signed by one of those authorities.
If however the certificate in your certificate store is a client certificate, meaning that you want GKE to be authenticating using that certificate to your backend, not sure that is possible.
There is a way to instruct nginx to use client certificates, something along the lines of this answer, which uses self-signed certificates:
https://serverfault.com/a/717926/370529
And there is a way to provide those snippets to an nginx ingress controller. But GKE does not use nginx. I don't know of a way to do the same with the GKE ingress controller.
I have been working with web services connecting to URLs provided by different clients and so far it has all been done using one-way authentication. Now I'm asked to enable 2-way (mutual) authentication for one of the clients. I did a lot of research and reading but still confused about a lot of things.
I could test successfully on my local machine following instructions from various different articles. But the problem is now to deploy it in production.
Here's what I did for testing: I created a test Web service Host and assigned it a self-signed certificate and created a client to test this. After this I created a client certificate using makecert and verified that this is installed via MMC. I then modified my Host app to only allow clients with certificate and tested from client to see the connection refused due to not providing the client certificate. Then I modified the bindings in the client application to include the certificate name and I was able to connect to the Host successfully. So this completes local hosting.
Now the real problem. The tech team is going to create a certificate in "cert store" on the server. And I need to test again to make sure everything works as expected. We have a few different developers who all want to test on their machines on their local code. Can we all use the same certificate somehow? I don't think we would be allowed to import the certificate but what suggestions could I give them so all of us can use the same certificate?
I'm also confused about issues like difference between windows certificate and IIS certificate. What advantages would the IIS certificate provide?
Thanks for help!
Edit: Could one of the differences between installing on IIS be so that the hosted sites be accessed via SSL connection? This would mean we don't really need to install on IIS if it's just a client certificate. Is this correct?
I have a domain that I purchased from Google and a heroku app that I'm trying to send it to.
I've done the steps in this article: https://www.justinvrooman.com/articles/how-to-use-heroku-with-google-domains
and yet when I try to access the site I get a
Your connection is not private
Attackers might be trying to steal your information from www.***.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
What am I doing wrong with my set up or why am I getting this message?
It looks like you've enabled SSL in your Rails app but your site doesn't have an SSL certificate configured. To disable SSL, set the following to "false" in your 'config/environments/production.rb' file.
config.force_ssl = false
In addition, in the same file, don't forget to set your "host" equal to your custom domain.
host = 'www.yourdomain.com'
If you want to run SSL on a custom domain (e.g. www.example.com) you'll need to purchase and configure an SSL certificate for your domain.
If, however, you are fine using Heroku's domain (e.g. example.herokuapp.com), then you can piggyback on Heroku's SSL certificate.
More info on running SSL on a custom domain through Heroku: https://devcenter.heroku.com/articles/ssl-endpoint
I have created a pem and crt file to use with my EC2 instance on AWS. I have 2 questions here:
1) The configuration instructions say: "Normally, at this stage you would submit your CSR to a Certificate Authority (CA) to apply for a digital server certificate." To whom do I send the certificate and how do I do it? Sorry, first time for me.
2) I am horribly confused about the uploading process to AWS. I have seen articles on uploading to a load balancer and uploading to IAM. I am using an EC2 instance and not, as far as I know a "load balancer" and I do not use IAM security. So how should I upload and what do I need to do?
Yours very confused seeking help ...
To get an SSL certificate signed you need to submit it to a trusted company, known as a Certificate Authority (CA). Think of your CSR like a blank cheque, nobody will trust it until it's signed by someone trustworthy.
There are commercial CAs which vary greatly in price, alternatively there are free CAs such as CACert (which I haven't used). The general process is: upload your CSR to the CA's site & the CA will provide a signed certificate.
If you want more information on what a CA's role is wikipedia is a great place to start, excerpt below:
In cryptography, a certificate authority or certification authority (CA) is an entity that issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or on assertions made by the private key that corresponds to the certified public key. In this model of trust relationships, a CA is a trusted third party – trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. Many[quantify] public-key infrastructure (PKI) schemes feature CAs.
For serving SSL traffic you have two options:
A common web pattern is to "Terminate SSL at the load balancer", which just means the load balancer will host and serve the SSL certificate, then simply sends traffic to the web server (your EC2 instance) via http. This is generally considered safe as the last hop is within your infrastructure.
If you want to go without a load balancer you'll need something on the EC2 instance to serve the SSL certificate. Here again there are plenty of options but generally installing Nginx or Apache on your instance to sit in front of your app works well.
Example configuration for Apache & Nginx are plenty & you should be able to find specific instructions for what-ever language & framework you're using but they're all fairly similar.
The play framework doco has examples for both Apache & Nginx sitting in front of a web app running on the same (EC2) server on port 9000 which should work for pretty much anything running on that port.
Plenty of reading to get you on your way, hope it helps!