2

I am hosting a domain in aws and want to allow https requests to it. I have done the following steps.

  1. requested a certificate from ACM, validated the emails and it is issued.
  2. created a classic load balancer (LB) with http and https listeners that forward to the instance through http(80).
  3. attached the certificate to the LB and added the instance that runs the website.
  4. made sure the security groups attached to the instance and LB have http(80) and https(443) in the inbound rules.
  5. the only outbound rule is (All traffic - All - All - 0.0.0.0/0) for both LB and instance security groups.

I then waited for the instance to be "inService" and tested the LB by browsing to its DNS and it opened. also http ://mydomain.com opened but when I tried https ://mydomain.com I get a message that the browser can't reach the server.
After some search I added the following 2 records.

  1. A record with name "mydomain.com" and value "LB domain.com".
  2. CNAME record with name "www" and value "mydomain.com".

I tried again but got the same results as above. Finally I came to an answer that I should enable https in my instance server.

when I did this and browsed I got a "Secure Connection Failed" with Error code "SSL_ERROR_RX_RECORD_TOO_LONG".

it looks like the LB doesn't terminate the https requests to my domain.
Any idea what I have done wrong!

Update: I removed the A record I created but when I made a DNS lookup, I found an A record pointing to my elastic ip. and although I have a CNAME record, the DNS lookup showed that I have no CNAME records.

Abdo Saied Anwar
  • 111
  • 2
  • 10
  • "I should enable https in my instance server" is incorrect. Did you wait for the DNS change to propagate? Also why do you mention "ssh" in your question title? – Mark B Mar 18 '17 at 18:27
  • yes the domain was already running without the LB. after I added the LB I waited until the instance status became "in service". do I need to wait after this ? I meant ssl I edited it – Abdo Saied Anwar Mar 18 '17 at 18:33
  • When you make a DNS change you have to wait for the change to propagate. This is completely unrelated to your instances being "in service" in your load balancer. Try to run `nslookup` from your local computer and verify that the domain is now pointing to the load balancer. – Mark B Mar 18 '17 at 18:36
  • it returned the elastic ip associated to my instance. should it return the ip of the load balancer ? – Abdo Saied Anwar Mar 18 '17 at 18:43
  • typically, how long does it take for the DNS change to propagate – Abdo Saied Anwar Mar 18 '17 at 18:55
  • 1
    @AbdoSaiedAnwar yes, it needs to return the address(es) of the load balancer. The delay in the visibility of the DNS updates depends on how you had the TTL set on the *old* DNS record -- before you changed it. "Propagation" is nearly instantaneous but the old record needs to time out before the new one will be visible. – Michael - sqlbot Mar 18 '17 at 19:02
  • now it has been about 15 hours since I created the A and CNAME record sets and nslookup is still not returning load balancer id. is there a way to know if it is still propagating or I did something wrong? I found that I can use get-change from CLI. but I created the records using the console and I don't have the change id. is there any other solution? @Michael-sqlbot – Abdo Saied Anwar Mar 19 '17 at 08:19
  • It's almost certainly not a Route 53 issue. Changes propagate there within seconds, so by now `get-change` would only tell you the change had been committed. Can you mention your domain name? That would be the easiest, since I or one of several othet SMEs who are probably reading this can use standard DNS tools to identify and then illustrate the problem. – Michael - sqlbot Mar 19 '17 at 12:53
  • it is reddobox.com – Abdo Saied Anwar Mar 19 '17 at 19:06
  • Thanks for laying out your steps. Your #4. solved my problem. – aero Jun 15 '17 at 16:52

3 Answers3

2

Ok, it was a silly mistake. the person who was working before me registered the domain name in godaddy and just pointed to the instance using A record on godaddy. so the records I added in route53 were meaningless. so I made a CNAME record in godaddy that resolves to the ELB DNS and every thing is working fine now.

For those who may be stuck in similar problem, I will try to write some advice.
First, when you choose to add a load balancer, then your instance shouldn't be directly accessed by clients. you should redirect users to the ELB and the ELB will do the rest. if you got your DNS from somewhere else rather than AWS, then follow the first paragraph in this answer. else if you have a working hosted zone for your domain in AWS then add an A record in Route53.
After this step if https is still not working. you can check whether the requests to your domain reaches the ELB or not. you can do this using load balancer log Access or cloudwatch. they both give you the requests that reached your loadbalancer. cloudwatch is simpler to use but log Access gives you more details for the request.
if requests don't reach then the record you added haven't propagated yet or you didn't add them in the right place (like I did).
if the requests did reach the ELB but there is still a problem then you might have missed something in the setup. make sure you make the 5 steps mentioned in the question. this video will be very helpful in this case.
Finally, it worth mentioning that if you use a certificate from ACM, you don't have to do any changes in the server running on your instance to make https work because in this case the ELB stands in front of your instance and it does all work for you. Of course you can make ssl between your ELB and instance but this is another story.

Abdo Saied Anwar
  • 111
  • 2
  • 10
1

I would like to add my case here. The error was returned in ECS cluster, docker container was exposed via the ECS cluster and load balancer to the external world.

I've got exactly the same error as was mentioned in the topic,

SSL_ERROR_RX_RECORD_TOO_LONG

however my DNS record used CNAME entry (A was mentioned in the comment above), so this part was correct.

You can split the troubleshooting of this error into the 2 stages: 1) -run docker container/s, don't use http, request an URL of the docker container, the command should be executed on the container instance that runs docker container:

curl localhost or curl localhost:

In my case this stage passed and curl returned an html response

2)check if your application load balancer can handle https traffic you can do this by executing a command:

> openssl s_client -connect <your dns host name connected to your load balancer>:443

in my case it turned out that the application load balancer was not able to properly handle ssl and handle a chain of certificates

Please find a sample of the command output for the load balancer that can not hanble https traffic below:

CONNECTED(00000003)
140181833668512:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 289 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1594020928
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

To fix the second problem I recreted an application load balancer, configured again https listener, pointed a certificate from the list of available certificates in my account and the problem was fixed.

Alex Konkin
  • 618
  • 1
  • 7
  • 15
  • Thank you. I created the ALB with a certificate, then changed the certificate. The new certificate was not configured when used `openssl`. Recreating the ALB with the new certificate worked like charm. – svex99 Aug 27 '23 at 01:56
0

InService will only come that time when you create something in /var/www/html/ . So I suggest you create an index.html file over there and wait 1 minute to see InService. After that, you have to point out CNAME to elb "address" which must be in lowercase in Router 53. But usually, it didn't become visible so just wait and keep refreshing until elb address appeared in Router 53. I hope it would work.

Aman Juman
  • 404
  • 5
  • 12