# \[SOLVED\] Https not working, new install

**URL:** <https://forums.rocket.chat/t/solved-https-not-working-new-install/6987>\
**Category:** Community Support\
**Created:** [May 19, 2020, 12:13am UTC](https://forums.rocket.chat/t/solved-https-not-working-new-install/6987 "2020-05-19T00:13:47Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![NevadaTech](https://avatars.discourse-cdn.com/v4/letter/n/aeb1de/32.png) [@NevadaTech](https://forums.rocket.chat/u/NevadaTech)\
**Post date:** [May 19, 2020, 12:13am UTC](https://forums.rocket.chat/t/solved-https-not-working-new-install/6987/1 "2020-05-19T00:13:47Z")

</div>

Hello!  
I’m new to RocketChat and having a devil of a time getting https to work. My setup is

- Ubuntu 18.04 (all updates applied)
- app installed via snap
- followed the Caddy instructions to get SSL going, no errors during install
- this is a hosted server at Ionos
- a subdomain has been created ([chat.domain.com](http://chat.domain.com))
- it works fine if I go to http:// chat.domain .com:3000
- it does not work if I go to https:// chat.domain .com:3000 \>\> Firefox Error code: SSL\_ERROR\_RX\_RECORD\_TOO\_LONG
- it does not work if I go to http:// chat.domain .com
- it does not work if I go to https:// chat.domain .com
- I’m running ufw on the box
- the box is directly on the public Internet
- checking Caddy status it shows active
- my Administration\> General\> Site URL shows https:// [chat.domain.com](http://chat.domain.com)

![rc_ufw](https://us1.discourse-cdn.com/flex021/uploads/rocketchat/original/2X/4/4dd3c8c9d514ee4a003d1fb4ed021dd7181b36ff.png)

I don’t think I need a reverse proxy (you tell me). Ignore the ‘http:// (space)chat’ or the (space).com, that’s just to get around forum limitation.

Any help would be appreciated.

---

<div class="post-metadata">

**Author:** ![NevadaTech](https://avatars.discourse-cdn.com/v4/letter/n/aeb1de/32.png) [@NevadaTech](https://forums.rocket.chat/u/NevadaTech)\
**Post date:** [May 19, 2020, 12:28am UTC](https://forums.rocket.chat/t/solved-https-not-working-new-install/6987/2 "2020-05-19T00:28:30Z")

</div>

## Rocket.Chat

| Version | 2.4.11 |
| --- | --- |
| Apps Engine Version | 1.11.2 |
| Database Migration | 170 |
| Database Migration Date | May 18, 2020 4:49 PM |
| Installed at | May 18, 2020 1:19 PM |
| Uptime | 22 minutes, 42 seconds |
| Deployment ID | blahblah |
| PID | 1121 |
| Running Instances | 1 |
| OpLog | Enabled |

## Runtime Environment

| OS Type | Linux |
| --- | --- |
| OS Platform | linux |
| OS Arch | x64 |
| OS Release | 4.15.0-101-generic |
| Node Version | v8.17.0 |
| Mongo Version | 3.6.14 |
| Mongo Storage Engine | wiredTiger |
| OS Uptime | 23 minutes, 9 seconds |
| OS Load Average | 0.00, 0.00, 0.00 |
| OS Total Memory | 1.92 GB |
| OS Free Memory | 559.09 MB |
| OS CPU Count | 2 |

---

<div class="post-metadata">

**Author:** ![anotherusername](https://avatars.discourse-cdn.com/v4/letter/a/977dab/32.png) [@anotherusername](https://forums.rocket.chat/u/anotherusername)\
**Post date:** [May 19, 2020, 9:00am UTC](https://forums.rocket.chat/t/solved-https-not-working-new-install/6987/3 "2020-05-19T09:00:56Z")

</div>

Instead of `3000` forward that to port `443`.

---

<div class="post-metadata">

**Author:** ![NevadaTech](https://avatars.discourse-cdn.com/v4/letter/n/aeb1de/32.png) [@NevadaTech](https://forums.rocket.chat/u/NevadaTech)\
**Post date:** [May 19, 2020, 9:00pm UTC](https://forums.rocket.chat/t/solved-https-not-working-new-install/6987/4 "2020-05-19T21:00:31Z")

</div>

Well, one of those FM (fricking magic) fixes. It started working on its own.

What I _think_ happened is that

- I had my [chat.domain.com](http://chat.domain.com) DNS entry
- ran the Caddy install for the Let’s Encrypt
- tested https, no go
- 2hrs later I though ‘Hey! Do I need port 80 open on the firewall for Let’s Encrypt?’ Let’s do that now.
- tested (and minor cfg changes) https for the next couple hours, still failed
- about 6hrs later I tried it and it worked fine
- my guess is that Let’s Encrypt failed straight off then it tried again and later Let’s resolved properly against port 80+443

I can now go straight to [https://chat.domain](https://chat.domain) with the SSL working and no :3000 port needed. Happy, happy now. Almost ready for production. Just backup and restore procedures need testing.

Thanks for the suggestion AnotherUserName but it wasn’t needed.