ssl validation of the SONOS service - sonos

We are preparing our service for SONOS.
We have found problem in only one test: ssl_validation.py
Our media files are located in AWS S3 bucket and they are url-signed.
https://.s3amazone.com/folder/file.mp3?Authentication part.
Sonos tests domain https://.s3amazone.com for ssl renegotiation providing the timeout error, which leads to the only one fail in tests. The question is how much it is important before moving APP for verification, or how to avoid this problem?
regards,Krzys

Related

Getting 'SSL_ERROR_BAD_CERT_DOMAIN' error after deploying site using Surge to a custom domain

I'm using Surge.sh to deploy a simple react app to a custom domain i bought from GoDaddy.com.
I've followed the instructions regarding custom domains on their site and get a confirmation that my site was deployed successfully:
https://surge.sh/help/adding-a-custom-domain
On GoDaddy I've configured the CNAME and A types to point to Surge:
However when I open up the domain at https://codatheory.dev/ I receive an error message with error code: SSL_ERROR_BAD_CERT_DOMAIN
I'm quite new to hosting sites on custom domains, so I'm sure I've misunderstood something. The certificate registered on the site is provided by surge.sh.
What configuration steps can I take to resolve this issue? Do I need to create a new certificate to be signed by a CA in order to use this domain, or have I missed something in my deployment?
Thanks!
SSl with surge comes out of the box with *.surge.sh domains. For these domains you can force a redirect of http to https. However, for custom domains surge does not offer SSL as stated explicitly here and they mentioned that it is a feature of surge plus. To answer your Q, yes you could generate a certificate using some provider (e.g. https://letsencrypt.org/) and add it to surge but that would be within the frame of surge plus (not the free tier anymore).
I would try if I were you maybe s3 with cloudfront? it does not cost that much if the traffic is not that high.

openshift ssl edge termination risk

I have been reading the Openshift documentation for secured (SSL) routes.
Since I use a free plan, I can only have an "Edge Termination" route, meaning the SSL is ended when external requests reach the router, with contents being transmitted from the router to the internal service via HTTP.
Is this secure ? I mean, part of the information transmission is done via HTTP in the end.
The connection between where the secure connection is terminated and your application which accepts the proxied plain HTTP request is all internal to the OpenShift cluster. It doesn't travel through any public network in the clear. Further, the way the software defined networking in OpenShift works, it is not possible for any other normal user to see that traffic, nor can applications running in other projects see the traffic.
The only people who might be able to see the traffic are administrators of the OpenShift cluster, but the same people could access your application container also. Any administrators of the system could access your application container even if using a pass through secure connection terminated with your application. So is the same situation as most managed hosting, where you rely on the administrators of the service to do the right thing.

Certificate credentials for WCF service on an Azure cloud service signed by our own CA

We have front and back end cloud service that communicate via WCF services which are secured using certificate credentials. The problem we are having is that the request fails with the following error:
verb="POST"
authenticationType="NOT_AVAILABLE" activityId="{00000000-0000-0000-0400-0080000000F7}"
failureReason="STATUS_CODE"
statusCode="403.16"
triggerStatusCode="403.16"
(From IIS failed request tracing)
I believe the issue is as described here:
https://support.microsoft.com/en-gb/help/252657/iis-5.0-http-403.16-forbidden-client-certificate-untrusted-or-invalid
(That the server does not trust third party CAs by default. )
If I do as described in the link the issue is resolved but the cloud service isn't part of a domain and I don't know how to apply this setting as part of the deployment or programmatically as part of the start-up.
What I also find strange is that this issue doesn't seem common even though I presume securing WCF communications on Azure cloud services using certificates isn't unusual, so I wonder if the issue is a symptom of something else I am doing wrongly.

SSL on Amazon S3 as "static website"

I have a bucket on S3 that needs to utilize the "static website" functionality in order to take advantage of the routing rules capabilities. Enabling this broke the built in ssl certificate. Is there a built in mechanism for supporting SSL requests on the S3 bucket while using the static website hosting? It seems like a major miss in functionality if this isn't present.
Also note that I need this to function outside of CloudFront as the hosted CSS suffers from CORS issues, which only the S3 bucket can resolve with its CORS Configuration options.
Thanks.
Static hosting and SSL do not work together. You could, as you know, use the ssl wildcard cert on the REST endpoint, but then you lose routing rules. And, as you have apparently found, Cloudfront's support for CORS is somewhat limited from what I can tell unless you have a very generous CORS policy.
From an AWS product manager on 2013-05-10:
Thanks for all your feedback. S3 static website hosting currently does not support SSL certificates. We may consider adding this support in the future. Please keep your feedback coming!
https://forums.aws.amazon.com/thread.jspa?threadID=60821#450167
The only noteworthy alternative that comes to mind -- which I have implemented successfully in the past -- is to use a reverse proxy (HAProxy? Nginx? Apache? Maybe even stunnel4? Others?) on EC2 in the same region to terminate the SSL and proxy the requests over to S3. In the same region, there are no bandwidth charges between EC2 and S3 so the only cost is that of the instance... which could still end up being less than the cost of using Cloudfront, and should perform comparably (without the caching aspect, of course).

How to Configure SSL for Amazon S3 bucket

I am using an Amazon S3 bucket for uploading and downloading of data using my .NET application. Now my question is: I want to access my S3 bucket using SSL. Is it possible to implement SSL for an Amazon s3 bucket?
You can access your files via SSL like this:
https://s3.amazonaws.com/bucket_name/images/logo.gif
If you use a custom domain for your bucket, you can use S3 and CloudFront together with your own SSL certificate (or generate a free one via Amazon Certificate Manager): http://aws.amazon.com/cloudfront/custom-ssl-domains/
Custom domain SSL certs were just added today for $600/cert/month. Sign up for your invite below:
http://aws.amazon.com/cloudfront/custom-ssl-domains/
Update: SNI customer provided certs are now available for no additional charge. Much cheaper than $600/mo, and with XP nearly killed off, it should work well for most use cases.
#skalee AWS has a mechanism for achieving what the poster asks for, "implement SSL for an Amazon s3 bucket", it's called CloudFront. I'm reading "implement" as "use my SSL certs," not "just put an S on the HTTP URL which I'm sure the OP could have surmised.
Since CloudFront costs exactly the same as S3 ($0.12/GB), but has a ton of additional features around SSL AND allows you to add your own SNI cert at no additional cost, it's the obvious fix for "implementing SSL" on your domain.
I found you can do this easily via the Cloud Flare service.
Set up a bucket, enable webhosting on the bucket and point the desired CNAME to that endpoint via Cloudflare... and pay for the service of course... but $5-$20 VS $600 is much easier to stomach.
Full detail here:
https://www.engaging.io/easy-way-to-configure-ssl-for-amazon-s3-bucket-via-cloudflare/
It is not possible directly with S3, but you can create a Cloud Front distribution from you bucket. Then go to certificate manager and request a certificate. Amazon gives them for free. Ones you have successfully confirmed the certification, assign it to your Cloud Front distribution. Also remember to set the rule to re-direct http to https.
I'm hosting couple of static websites on Amazon S3, like my personal website to which I have assigned the SSL certificate as they have the Cloud Front distribution.
If you really need it, consider redirections.
For example, on request to assets.my-domain.example.com/path/to/file you could perform a 301 or 302 redirection to my-bucket-name.s3.amazonaws.com/path/to/file or s3.amazonaws.com/my-bucket-name/path/to/file (please remember that in the first case my-bucket-name cannot contain any dots, otherwise it won't match *.s3.amazonaws.com, s3.amazonaws.com stated in S3 certificate).
Not tested, but I believe it would work. I see few gotchas, however.
The first one is pretty obvious, an additional request to get this redirection. And I doubt you could use redirection server provided by your domain name registrar — you'd have to upload proper certificate there somehow — so you have to use your own server for this.
The second one is that you can have urls with your domain name in page source code, but when for example user opens the pic in separate tab, then address bar will display the target url.
As mentioned before, you cannot create free certificates for S3 buckets. However, you can create Cloud Front distribution and then assign the certificate for the Cloud Front instead. You request the certificate for your domain and then just assign it to the Cloud Front distribution in the Cloud Front settings. I've used this method to serve static websites via SSL as well as serve static files.
For static website creation Amazon is the go to place. It is really affordable to get a static website with SSL.