I'm struggling to use AWS Cloud Former to generate a CloudFormation template. I have already launched the Cloud Former stack twice and attempted to connect to the associated DNS for the EC2 instance generated each time and keep receiving the error pictured below.
I have already tried to create a new SSL certification for the EC2 instance via AWS Certificate Manager, but AWS does not allow this for EC2 instances. I'm not very familiar with SSL/HTTPS processes and would appreciate any guidance on next steps I should pursue to address/troubleshoot this.
Upon further research into this, I have found the following issue:
Specifically, I'm seeing the following SSL certification issue:
Has anyone else seen this yet with CloudFormer recently?
CloudFormer uses self signed certificates that are generated by the stack. This is the normal browser warning when the browser encounters a self signed certificate. For your purposes, you can simply click on the link at the bottom (Proceed to EC2-xxx (Unsafe)) of the warning page, and ignore the warning. You will connect successfully in spite of the warning.
SSL certificates require a domain. On AWS you can set one up with the certificate manager, but it will still have an issue until you correctly configure Route 53 on AWS as well.
Related
I've set up my app running on Cloud Run with a Let's Encrypt wildcard certificate to cover subdomains. It works fine, but everytime I run testssl.sh or other similar tools they notice 2 certificates: mine and Google's. The second certificate throws errors regarding name mismatch and from time to time (couldn't reproduce it, it may not be a problem) even browser notice this and say the cert is not valid, but a refresh will fix it.
Is this something common and should I ignore it? Google's DIG shows that the domain has the correct IP as A record and everything else works fine.
Use only one certificate.
A wildcard certificate with Cloud Run provides few benefits. Only domain names that are mapped will be supported so the wildcard does not help. The negative is that you must manually renew the certificate every 90 days.
Use the Google Managed certificates.
I have a problem when using a custom CNAME and SSL/HTTPS for a CloudFront distribution. I set up a CloudFront distribution to use as a CDN on my WordPress site, using the W3TC plugin to configure things.
I imported an SSL certificate from my hosting provider to use with the CloudFront distribution. I also configured a CNAME at my hosting for the distribution (e.g., "cdn.example.com") to use in place of the CloudFront domain name (e.g., "d1234.cloudfront.net").
After setting all this up I immediately noticed that all the images were just broken image links. Right-clicking an image to open it in a new browser window resulted in the browser warning me that "the connection is not private" and that the website "may be impersonating cdn.example.com". The source showed that none of the CloudFront CDN resources were being loaded. Chrome reported "Failed to load resource: net::ERR_CERT_COMMON_NAME_INVALID" for several resources.
After experimenting I found that if, I stopped using the CNAME (by removing it from the W3TC plugin field) and used the CloudFront domain name (i.e., "d1234.cloudfront.net") instead, everything worked all right. So images loaded successfully from d1234.cloudfront.net, where they wouldn't from cdn.example.com.
I have another site that is set up exactly the same except it doesn't use SSL/HTTPS: the use of a custom CNAME for the CloudFront distribution there doesn't cause any problems at all.
So the problem with CloudFront seems to appear when I try to use SSL/HTTPS and a custom CNAME.
The Chrome error report seems to indicate that there's a problem with the SSL certificate that I imported (what, I don't know - I'm not at all clued-up with SSL certificates). If that's the cause of the problem, should I get a certificate from AWS to enable the use of a custom CNAME? If so, what should I stipulate for the certificate? And I'm not sure how that works having two certificates - one for my domain and another for CloudFront?
It sounds like you may have missed adding your CNAME to the Cloudfront distribution, i.e. under 'Alternate Domains Names':-
(I know this is an old question but as it stands unresolved and I just hit the same issue, I think this might help others)
Below are the issues.
Certificate does not match issuers name
Google Chrome browser error
Address error due Certificate Mismatch
Please check SSL generated for domain is valid and uploaded same to cloudfront.
This is my first time getting an SSL certificate for my website. I followed this tutorial https://devcenter.heroku.com/articles/automated-certificate-management
heroku certs:auto displays that Status is "Cert issued". I get no errors. I use git push and the website is still not certified. What could I be doing wrong?
Old question, but if anyone else runs into this problem, which I was just battling myself, here was my problem:
When following the Heroku dev center guide on how to point a custom domain to your herokuapp, the guide says, among other things:
"Create a CNAME record to map from www.example.com to example.herokuapp.com or your SSL endpoint if using SSL."
Neither one of these alternatives are, however, the way to go now (SSL endpoint is considered legacy at Heroku). Instead, once you have added your custom domain correctly, simply:
In Heroku CLI, run "heroku certs:auto:enable" to enable ACM.
Point your domain's DNS records at the Heroku DNS target for your custom domain, which you can find by running "heroku domains"
Wait a little.
This should do it.
I have a Synology NAS DiskStation DS2415+. When I bought it several years ago, I followed the setup instructions and created a self-stamped certificate which worked and even allowed me to remotely connect to my NAS via HTTPS.
Recently I changed some settings following the Synology's "Security Advisor" which is an automatic tool which scans all settings and recommend changes to secure it.
Following the recommendations of the said tool, I made some the reuqired changes, mostly in the Network Settings and Security Settings, but now I now can't use Quick Connect without getting a warning. In case any of you is familiar with this issue, I do hope there is a way to use HTTPS and not HTTP, either with a self stamp SSL or a purchased one. When I inquired about purchasing an SSL, I am told that it would be impossible to use an SSL without a dedicated domain for that SSL, but that's a side issue because originally my NAS worked and was remotely accessed via a self stamped certificate.
I managed to fix it by the following steps:
Creating a Self Stamped SSL (done in 2 steps)
1. Go to Control Panel -> Security -> Certificate -> CSR
Generate the CSR and download it. Use your user name as the Common name.
Go again to Certificate -> CSR and this time select Sign Certificate Signing Request. You will then be asked to select the .csr file from before, and as a result, the certificate will be downloaded.
Go to your browser and import this certificate. (Thanks #Matt Clark !)
In my case, only after going to Chrome -> Settings -> Advance and selecting Reset Settings to Default, it worked.
I can now connect to my NAS using QuickConnect and using HTTPS.
My SSL Certificate on my AWS Elastic Load Balancer is going to expire very soon and I need to replace it with a new one.
I've got the new certificate / bundle / key, uploaded to IAM but it won't show in the drop down in the Load Balancer settings that should let me choose the certificate to apply.
Here is the output when I put
aws iam list-server-certificates
To my mind this shows that I have uploaded the new certificate to IAM ok. The top certificate in the list is the one which is due to expire any moment now and the other two are ones I have recently uploaded with the intention of replacing it (They are actually two attempts to upload using the same pem files).
The image below shows that only one certificate is available to choose to apply to the load balancer. Unfortunately it is the one that is about to expire.
The one thing that does strike me as a little odd is that the certificate name in the dropdown - ptdsslcert - is different to the names in the aws iam list-server-certificates output, even though it is the same certificate that expires imminently.
I'm really stuck here and if I don't figure this out soon I'm going to have an expired certificate on my domain so I would be really appreciative of any help on this.
The AWS CLI uses a provider chain to look for AWS credentials in a number of different places, including system or user environment variables and local AWS configuration files.
http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html
Although it's hard to guess the specific local machine configuration issue that resulted in the behavior observed, as noted in the comments, this appeared to be an issue where aws cli was using two different sets of credentials to access two different services, and these two sets of credentials were actually from two different AWS accounts.
The ServerCertificateName returned by the API (accessed through the CLI) should have matched the certificate name shown in the console drop-down for Elastic Load Balancer certificate selection.
The composition of ARNs (Amazon Resource Names) varies by service, but often includes the AWS account number. In this case, the account number shown in the CLI output did not match what was visible in the AWS console... leading to the conclusion that the issue was that an AWS account other than the intended one was being accessed by aws cli.
As cross-confirmed by the differing display names, the "existing" certificate, uploaded a year ago, may have had the same content but was in fact a different IAM entity than the one seen in the dropdown, as the two certificates were associated with entirely different accounts.