We have updated and installed our new SSL certificate on GCP. Everything looks OK. The previous SSL certificate is still valid and assigned to a proxy group.
Question:
How can we assign the new certificate to the proxy groups?
Or does the certificate switch as soon as the previous expires and we don't have to take any action yet
Many thanks for your help
Network tab view SSL certificates
The load balancer can serve the expired certificate if the certificate is still associated. Once you upload a new self-managed certificate, remove the older ones.
When the SNI hostname matches CNs or SANs in more than one
certificate, the certificate selection is based on client-specific and
internal factors that cannot be predicted. One of the certificates
matching the SNI is returned. The load balancer can also serve the
expired certificate if the expired certificate is still associated
with the target proxy.
Multiple SSL certificates
I created a front-end hosted at www.example.com through netlify. The front-end makes API calls to a load balancer address hosted on AWS. Through Netlify, I set up an A record, so that server.example.com points to the load balancer. In Amazon Certificate Manager, I got certificate imported successfully for example.com and server.example.com by creating CNAME records in Netlify.
However, when I visit server.example.com in the browser, it properly loads my Express Server, but it says Not Secure in the browser despite being served over https. It says the certificate is invalid.
I'm wondering how to get the certificate to be valid at server.example.com - any help would be much appreciated, as I've struggled with this for two days now.
Thanks!
The issue is that the certificate CN (common name) is drawafterdark.com and you are using it with server.drawafterdark.com. The certificate is valid but client (Chrome) will show that certificate is not valid because hostname doesn't match the CN. You either have to get the certificate for server.drawafterdark.com or wildcard certficate *.drawafterdark.com
You can also add server.drawafterdark.com to the SAN subject alternative name. Then it will we be validate it for both server.drawafterdark.com and drawafterdark.com
I had set up Cloudfront correctly over http. It fetched data from my website (dev.pie.video) fine. I'm now moving to https. Things are working fine at https://dev.pie.video but Cloudfront is unable to server any content.
For instance https://dev.pie.video/favicon-96x96.png works but https://d1mbpc40mdbs3p.cloudfront.net/favicon-96x96.png fails with status 502, even though my Cloudfront distribution d1mbpc40mdbs3p points to dev.pie.video.
More details if that's helpful:
d1mbpc40mdbs3p.cloudfront.net uses the default CloudFront Certificate for https
the cloudfront distribution's origin is set to work over SSL and TLS, and to use the viewer's protocol.
===== Edit 1 =====
screenshots of the cloudfront settings:
General:
Origin:
Behaviors:
==== Edit 2 ====
if that's helpful, the logs I'm getting from cloudfront look like
<timestamp> SFO20 924 96.90.217.130 GET d1mbpc40mdbs3p.cloudfront.net /favicon-96x96.png 502 - <someInfoOnTheClientBrowser> 2 - Error poZyhl63JNGFk8dIIjCluGDm4dxF8EdMZFhjg82NgHGPNqcmx6ArHA== d1mbpc40mdbs3p.cloudfront.net https 494 0.002 - TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 Error HTTP/1.1
Your origin server is incorrectly configured for SSL. CloudFront requires a valid configuration, and may be more stringent than some browsers -- so a green lock in the browser doesn't necessarily mean your SSL setup is complete and universally compatible with all clients.
$ true | openssl s_client -connect dev.pie.video:443 -showcerts
CONNECTED(00000003)
depth=0 OU = Domain Control Validated, CN = dev.pie.video
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = Domain Control Validated, CN = dev.pie.video
verify error:num=27:certificate not trusted
verify return:1
depth=0 OU = Domain Control Validated, CN = dev.pie.video
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/CN=dev.pie.video
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
-----BEGIN CERTIFICATE-----
MIIFMzCCBBugAwIBAgIJAL96wtFpu1ZpMA0GCSqGSIb3DQEBCwUAMIG0MQswCQYD
VQQGEwJVUzEQMA4GA1UECBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEa
MBgGA1UEChMRR29EYWRkeS5jb20sIEluYy4xLTArBgNVBAsTJGh0dHA6Ly9jZXJ0
cy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5LzEzMDEGA1UEAxMqR28gRGFkZHkgU2Vj
dXJlIENlcnRpZmljYXRlIEF1dGhvcml0eSAtIEcyMB4XDTE2MDgwODE4MzQ0MFoX
DTE3MDgwODE4MzQ0MFowOzEhMB8GA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRh
dGVkMRYwFAYDVQQDEw1kZXYucGllLnZpZGVvMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAz/wT5j/zHKzmt3oRvst74Knqxc0pl3sp5imUJ7UegoxcTISm
xJC5qQiDsD0U08kAFxvXDd91jlozh4QDcfLE8N7X9fsxC7OW2pDv3ks/LO7tiCxn
gNmxjvYvOQ/vASrLHIal+oGWJNdBMB1eckV4xHCeBDDEizDneq/qvjN0M0k5hQ+/
qk7RjVhJUmFAfvhXpxXaCbVDq1d3V1iRBo3oP3SGV++bj/m55QPFfKCZqGPTiM5G
c9+8ru16EVCpvs0wCWBVxjTiOCGtrMLgvp9LOs8AN369Yk/3AynpgAI0DDhb5y8I
KEuCdbUaIg5Zo029iZz4nWRsZFd5CSwgX8tZNQIDAQABo4IBvjCCAbowDAYDVR0T
AQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/
BAQDAgWgMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly9jcmwuZ29kYWRkeS5jb20v
Z2RpZzJzMS0yODIuY3JsMF0GA1UdIARWMFQwSAYLYIZIAYb9bQEHFwEwOTA3Bggr
BgEFBQcCARYraHR0cDovL2NlcnRpZmljYXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0
b3J5LzAIBgZngQwBAgEwdgYIKwYBBQUHAQEEajBoMCQGCCsGAQUFBzABhhhodHRw
Oi8vb2NzcC5nb2RhZGR5LmNvbS8wQAYIKwYBBQUHMAKGNGh0dHA6Ly9jZXJ0aWZp
Y2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9nZGlnMi5jcnQwHwYDVR0jBBgw
FoAUQMK9J47MNIMwojPX+2yz8LQsgM4wKwYDVR0RBCQwIoINZGV2LnBpZS52aWRl
b4IRd3d3LmRldi5waWUudmlkZW8wHQYDVR0OBBYEFEPW+uDOOtZfUEdXuBs+960C
zQRKMA0GCSqGSIb3DQEBCwUAA4IBAQBLkLYJEc9E+IGv6pXaPCcYowJfji651Ju6
3DNzGXdyWfOXG+UVCMtPZuC9J66dID4Rc7HWzLveTPEI32z4IgtSjvRwRk9YyWVx
uCOpsP3e/Vgriwg5ds4NyrelQfshA3KaiTLohuiVEOBZgZgIwBEmwR2ZNFuL375E
uEn909zF9+sGkTbFnMm1zlqB2oh2UlSkUT3mj009vWF416W6kZQdFFFEmaI8uSmo
+Thd8HSxQytzWvB3dR4lCteiC09lkQPHU5t10tPgK9BtkLv05ICQQoDhFJmLeAcC
WNEmCcDnSHPxXjPi8kcyM6aqNofL1D0e1pYYvcpYQQDayWdY3tUh
-----END CERTIFICATE-----
---
Server certificate
subject=/OU=Domain Control Validated/CN=dev.pie.video
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
---
No client certificate CA names sent
---
SSL handshake has read 2010 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
...clipped...
Your certificate is signed by "Go Daddy Secure Certificate Authority - G2" which is an intermediate certificate (not a root), and you don't have that intermediate certificate installed on your server -- so CloudFront reports that it is "unable" to connect, when in fact it is more accurately "unwilling" to connect, as a security precaution, because it can't verify the validity of your SSL certificate. You should see these as SSL negotiation failures in your web server's log. The connection itself is working, but CloudFront considers it invalid, and therefore unsafe to use, due to the trust issue.
Caution
If the origin server returns an expired certificate, an invalid certificate or a self-signed certificate, or if the origin server returns the certificate chain in the wrong order, CloudFront drops the TCP connection, returns HTTP error code 502, and sets the X-Cache header to Error from cloudfront.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecureConnections.html
Add your intermediate certificate to your server configuration, and you should be set. This should have been bundled with the cert when you downloaded it, but if not, it can be obtained from your CA, Go Daddy in this case.
This is not a limitation specific to Go Daddy certificates. All CAs that follow standard practice use intermediate certificates to establish a chain of trust back to a trusted root.
See also:
https://www.godaddy.com/help/what-is-an-intermediate-certificate-868
https://certs.godaddy.com/repository
In case it helps ( I am new to Lightsail )
I had a similar issue, when creating a Lightsail Distribution.
TLDR: try setting Origin protocol policy to be HTTP (since your origin indeed is only able to serve up HTTP unless you also add the SSL cert there)
DETAIL
I followed the documentation, in particular https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-creating-content-delivery-network-distribution#distribution-origin-protocol-policy
I created:
Lightsail instance (PHP bitnami image)
configured Distribution for a dynamic site, and to use HTTPS, by creating a SSL cert
created a DNS zone
configured domain to point to the nameservers of that DNS zone
configured A + CNAME records in the DNS records in DNS zone, to point to the distribution
error: browser shows 502 error page
The problem I had was that "Origin protocol policy" was set to HTTPS only, although the Lightsail instance could only serve up HTTP.
I changed "Original protocol policy" to HTTP and then the page serves OK (as HTTPS).
It seems that SSL cert and HTTPS can be handled entirely by the Distribution, and do not need to be configured on the Instance (provided you set "Origin protocol policy" to HTTP).
So a crude high level picture, looks like:
browser <-- https --> Distribution <-- http --> Instance
Of course, the downside is that my Lightsail instance is serving pages as HTTP, to anyone who knows its static IP address...
I got the same issue. I did below steps:
Looked at ALB Lister tab and checked for the port of 443.
There were two certs out of which one was expired and ALB was pointing to newer one but still we were getting 502 error.
AWS support suggested to remove the expired from 443 listener.
Thanks
Santosh Garole
I had similar issue I fixed by not selecting website endpoint when selecting origin even though it is prompted to use it.
In my case even cloudfront ssl certificate was not working however I was able to connect through website endpoint without cloudfront.
Also I needed to set default root object to index.html in order to get it working.
I've had this issue when using CloudFront (Amazon) on top of CloudFlare (different company). They surely have their https certificates correct?
Didn't get to the bottom of it and I just switched back to http for the origin. It was just images for a stupid ebay store and I was really only using CloudFront to obfuscate the domain underneath (because people steal image URLs on ebay).
I added a query string parameter ?a=1 and it worked, ?a=2 failed, ?a=3 worked, ?a=4 worked and ?a=8 failed again. So there was something funky going on with either CloudFront's
Still not sure what was going on but invalidation didn't fix it, neither would have I expected it to since I pass through query strings and changing a did not make it always work.
if you get the problem try adding a nonsense parameter and incrementing it several times and observe the results.
I created a SSL certificate for my site using Amazon Certificate Manager. The certificate is for *.example.com. I have then attached this certificate to my ELB and have left the instance protocol as http. So SSL chain is only between the client and ELB.
I have two A records in Route53. One for example.com one for www.example.com. Both of these are aliased to ELB. When I do https://www.example.com it works perfect. But when I do https://example.com I get the following error in FireFox:
"example.com uses an invalid security certificate. The certificate is only valid for *.example.com Error code: SSL_ERROR_BAD_CERT_DOMAIN"
Shouldn't the certificate *.example.com work for the address example.com? Am I missing something?
EDIT May 31, 2016
Thank you to Steffen Ullrich for setting me on the right track. The problem is when using the AWS Certificate Manager (ACM) in the console (web browser) there is no option to add the alternative names. For those having the same problem you need to use CLI (command line interface). A quick web search for "Install AWS CLI" will give you all the information you need to complete the installation. Once CLI is installed then you can run the ACM commands. Here is a link to the documentation:
http://docs.aws.amazon.com/cli/latest/reference/acm/request-certificate.html
The command I used was:
aws acm request-certificate --domain-name www.example.com --subject-alternative-names example.com
Once the request was approved I was able to see the SSL certificate in the ACM web interface. I installed it and everything working like a charm now!
A certificate for *.example.com matches whatever.example.com but not example.com only. This is because the * must match a label and example.com has no label in place of the *. If you want to match both whatever.example.com and example.com you need to create a certificate which has as subject alternative names both *.example.com and example.com.
When requesting a new certificate via the console, you can now add both *.domain.com and www.domain.com, before hitting next, in the next box, make sure you request to add another domain to the certificate.
firstly this is my first experience installing an SSL/TLS cert so please forgive my ignorance/innocence on the topic.
I have an EC2 instance set up with a load balance running in the EU (Ireland) region, unfortunately the AWS Certificate Manager isn't available yet (any plans to introduce it there?? :) ), so I am getting a cert and installing it myself. My website will be using Stripe, which says you have to use SSl and I am just wondering if the positive SSL from Comodo will be enough? I don't really have the cash for $100+ EV cert at the moment. I know that might be a question for Stripe, but someone might know.
The part that I am wondering about AWS is, if I get the positive SSL cert and upload it through the AWS console to IAM (by adding a HTTPS listener to the load balancer), do I then have to install the certificate on my actual EC2 instance also, or is just doing it once through the console enough? Does that just mean that the https will be from a users browser to my load balancer, and not from my load balancer to my server? If I am going to have payments through my site is this a bad set up? Should I be getting a different cert?
Is just installing the positiveSSL cert through the console enough that my site will now be accessible through https://example.com and it doesn't have the green lock, or will it still be http://example.com and the HTTPS stuff just goes on in the background.
Sorry if this is an annoying question / doesn't make sense. I am just trying to wrap my head around it all. Thanks!
Stripe details this well:
Do I need to use SSL/TLS on my payment pages?
Yes ... It's more secure
and
What if I don't want to set up SSL/TLS yet?
You can test your page--but not live transactions--before installing your SSL/TLS certificate. You don't need to enable HTTPS until you're ready to go live.
To test live transactions without your own SSL/TLS certificate, you could host your site with a provider that provides a secure subdomain. For example, Heroku allows you to host at https://yourapp.heroku.com.
Ultimately, your site doesn't need to be PCI compliant, as Stripe handles all the credit card information. Clearly they don't set a "stripe compliant" standard for the SSL cert.