AWS CA ssl certificates not working? - amazon-web-services

I created a CSR on the AWS Linux server and used this to create a self signed CA certificate which I then installed but get common name and host name mismatch errors.
Can somebody tell me what I have to do to correct the problem as the common name IP is internal to Amazon and the host IP is public so how do I create a workable certificate?
I am not a programmer but this is the last step of my site development. SSL is fine But I need to get the certificate working. Thanks

I did use my domain.net as the common name but I think he answer lies in my changing the hostname on the AWS /etc/sysconfig/network file. This was set as HOSTNAME=localhost.local when I created the original CSR.pem file and certificate.
I changed localhost.local to mydomain.net, created another csr.pem file and certificate and SSL is working. I should add I previously created an elastic IP and attached this to the server and in Route 53 allocated the domain name to the instance. There was no information to change the instance HOSTNAME in the network file.
When you find the answer its obvious, finding the answer was the problem.
Many thanks

Related

AWS EC2 certificate issue

I was deploying my Spring Boot app using AWS EC2 and S3 by running a jar file on a virtual machine. However, I'm facing a security issue when trying to fetch this url from the browser, which listens to port 8443: https://ec2-3-20-235-15.us-east-2.compute.amazonaws.com:8443/
However, I'm getting , which say NET::ERR_CERT_COMMON_NAME_INVALID. I've been trying to look into how to get SSL certificates for my EC2 instance, but have not found a way yet. I would really appreciate any help on how to properly set this up. I'm completely new to AWS...
Thank you.
Your ssl certificate has a custom domain name, but you are trying to access your ec2 using the default ec2 URI which use amazonaws.com domain, so you need to create a cname record in your custom domain to point ec2 URI.

Add wildcard ssl in multiple ec2

Problem Summary:
Hi i have one wildcard ssl which is installed in IIS on AWS EC2 instance.
This is working fine
Now i need to create another EC2 instance and use same ssl to the new instance IIS.
Current Stage:
I created new instance and installed IIS and working fine. I have http and https inbound access so currently i can access default IIS page from outside with instance public address.
Now i installed same SSL certificate in the IIS. I configured ssl in my new website and done. But this is not working. When i try with https i got 404.
Please help me to identify the issues.
Any restriction to use wildcard in multiple instances' IIS in same account
Any correct method to do this? I don't dont want load balancer now
Update:
I tried to configure in my local machine.
Step 1: I created a sample WebAPI and run in 8090 port with http. It shows like below as expected.
Step 2: I added https bindings with my ssl certificate but not gave any host name.
Step 3: Now I added sample host name (ssltest.mydomain)
I didn't get any idea on this. Please help
Any restriction to use wildcard in multiple instances' IIS in same account
There are no restrictions on how often a certificate can be used
Any correct method to do this?
There is nothing special about it, i.e. there is no difference between installing two different certificates on two hosts or the same certificate on two hosts. You likely did something wrong but it is unclear what exactly.
Note that a HTTP response code 404 actually means that the certificate itself is working since otherwise you would get a certificate error which comes before the HTTP response. So there is likely some misconfiguration which is not related to the certificate.

AWS Elastic IP pointed to new instance does not work

I created an AMI of my server on AWS, and spun up a new instance.
When I point my elastic IP address to my new instance and type in my domain name I get a timeout error when going to my website.
I have done backups before and just re-pointed my elastic IP but this time it does not seem to be working, any ideas?
Steps I take on AWS:
I click on my elastic IP and pick actions-> Associate Address
Resource type = Instance
Instance: I select the new instance I just made by copying my old instance
Reassociation: I click the checkbox to allow Allow Elastic IP to be reassociated if already attached
I click associate
When I go to my webpage I get this error in edge:
Error Code: DLG_FLAGS_INVALID_CA
DLG_FLAGS_SEC_CERT_CN_INVALID
When I click proceed I get this instead of my website (Chrome would not allow me to proceed):
Looks like some sort of certificate issue...
The error I get in chrome is:
NET::ERR_CERT_AUTHORITY_INVALID
Can you please check server of which type (EC2-VPC or Classic).
You can't associate an Elastic IP address that you allocated for use with a VPC with an instance in EC2-Classic, and vice-versa.
If this is the case you can migrate Elastic IP from classic to EC2-VPC.
The SSL certificate is invalid, or not installed correctly. It is not related to the EIP at all.
This site is not secureā€ is a security alert that prevents users from accessing various websites. In the technical language, this error is known under the name of DLG_FLAGS_SEC_CERT_CN_INVALID. The
ou will need to provide more information about the cert, how it was issued, etc. to do any further troubleshooting.
See https://tecoreviews.com/how-to/fix-site-not-secure-pop-error-code-dlg_flags_sec_cert_cn_invalid/
The error message NET::ERR_CERT_AUTHORITY_INVALID is also related to the certificate.
Given these messages, I suspect the certificate has a common name mismatch, a root CA certificate is missing, or it's a self signed certificate.
Check the certificate details carefully as presented in the browser. The browser itself is rejecting the cert. Check globalsign.com/en/blog/how-to-view-ssl-certificate-details and review. It should be clear why the cert is being rejected. When you see the specific error, you can figure out the cause and then fix it.
The domain name is key. When the SSL cert was created you provided a Common Name (i.e. domain name). Some SSL certificates cover subdomains (wildcard certificates issued for e.g '*.example.com') some don't (ie. www.example.com only). If you have the latter kind you need to use the exact same domain to address the new box.
I did not update my security groups correctly so web traffic wasn't allowed.

Set up SSL in Elastic Beanstalk using cloudHSM

I'm familiar with creating a CSR (via openssl) on a webserver and submitting it to a CA to purchase an SSL cert.
A site we're building (using Elastic Beanstalk) has a requirement that certificates are managed via a HSM. I think AWS CloudHSM is the correct tool to use here? I have:
Created the EB environment in a VPC with public and private subnets
Requested and assigned an SSL cert to the environment via AWS Cert
Manager (at this point, I have a working site over https, just no HSM)
Created a HSM cluster in the same VPC, and downloaded its
CSR.
At this point, the docs (http://docs.aws.amazon.com/cloudhsm/latest/userguide/initialize-cluster.html#sign-csr) leave me a bit stuck.
It says, "Your CA signs the CSR, which creates a signed certificate. Then you provide the signed certificate and your CA's issuing certificate to initialize the cluster."
Fine. Except if I try to upload this CSR to (ie, Verisign, GlobalSign) I get "Certificates with internal names are no longer permitted". Which makes sense - I'm not requesting a cert for a site's external domain name, the cert is for the HSM: which, I'm guessing, I'll then use to create an openssl cert once its CSR has been signed.
Basically, I'm very confused about how a HSM fits into the otherwise simple SSL-requesting procedure of: generate CSR, submit to CA, install cert on webserver. Especially given my added complications of doing this all with Elastic Beanstalk and AWS ACM rather than just dumping a cert file on the server and updating the Nginx conf.
How does it all work ??
Since posting this question a year ago, AWS have updated their documentation on how to set up SSL offload with a CloudHSM. By following that documentation, I was able to set up a separate EC2 instance - outside of ElasticBeanstalk - for SSL termination. It's still not possible, AFAIK, to use a CloudHSM directly from within ElasticBeanstalk.

Browser certificate warnings for wilcard domain SSL certificate installed on Amazon ELB

I've setup an Amazon Elastic Load Balancer instance to provide SSL termination to the EC2 instances it balances.
The certificate is a wildcard domain variant provided by 123-reg. Verifying the SSL installation using the associated root authority (GlobalSign) using their validation tooling shows 2 issues:
Server configuration does not include all intermediate certificates
Hostname in certificate and DNS name do not match
I have been unable to get the ELB instance to accept the certificate chain, and as this is optional have left this out for now. Googling around this issue all I can find is that for browser based consumers of the load balanced resources this is not infact optional and will lead to issues. However, I have been unable to find any information about what issues this will cause. Specifically - is the lack of a certificate chain the reason I am getting the hostname mismatch warning?
If the lack of a certificate chain is not the reason for the second validation error, does anyone have any idea of what else could be the issue. Some key points are:
I have setup the friendly DNS for the load balancer as a CNAME pointing to the DNS shown in the AWS console for the ELB (though it says its actually an A record ...)
The instances behind the load balancer are Windows boxes, with the domain names they server added to their respective hosts.ini
I have verified the certificate CN is correct and is *.OURDOMAIN.com as required for a wildcard certificate.
UPDATE - The domains I am trying to host are actually multi-level subdomains which appears to be the problem.
NOTE I am not especially looking for advise on how to upload the certificate chain as this is pretty well covered elsewhere on StackOverflow (although I can't get it to work all the same!). Rather, is the lack of certificate chain the root cause for the hostname/DNS name mismatch, which is what I have been unable to fathom.