# Unable To Connect/Connection Refused due to https certificates

**URL:** https://meta.discourse.org/t/unable-to-connect-connection-refused-due-to-https-certificates/51276
**Category:** Self-hosting
**Created:** [8 Ottobre 2016, 11:52pm UTC](https://meta.discourse.org/t/unable-to-connect-connection-refused-due-to-https-certificates/51276 "2016-10-08T23:52:43Z")
**Posts on this page:** 10
**Page:** 1

<div class="post-metadata">

### Author: ![GregoryMatthews](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/gregorymatthews/32/120656_2.png) [@GregoryMatthews](https://meta.discourse.org/u/GregoryMatthews)
#### Post date: [8 Ottobre 2016, 11:52pm UTC](https://meta.discourse.org/t/unable-to-connect-connection-refused-due-to-https-certificates/51276/1 "2016-10-08T23:52:43Z")

</div>

We successfully installed Discourse through DigitalOcean using the following guide:

[discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub](http://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md)

Our DNS is fully propagated, and we also installed our SSL CERTS per the following guide:

> [@Allow SSL / HTTPS for your Discourse Docker setup](https://meta.discourse.org/t/allowing-ssl-https-for-your-discourse-docker-setup/13847):
>
> This guide is likely out of date as there are now very few reasons not to use the built-in Let’s Encrypt certificate that Just Works. See also: 2023-04-10 @pfaffman says: This is left here mostly for historical purposes. So you’d like to enable SSL for your Docker-based Discourse setup? Let’s do it! This guide assumes you used all the [standard install](https://meta.discourse.org/t/142537?silent=true) defaults – a container configuration file at/var/discourse/containers/app.yml and Discourse docker is installed at: /var/discourse Buy a SS…

When browsing to our Discourse installation via IP or domain name, we get the following message:

This site can’t be reached

```
XX.XX.XX.XX refused to connect.
Try:
Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_REFUSED

```

What could be the problem?

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [9 Ottobre 2016, 12:18am UTC](https://meta.discourse.org/t/unable-to-connect-connection-refused-due-to-https-certificates/51276/2 "2016-10-09T00:18:49Z")

</div>

Almost certainly a SSL problem. Try rebuilding with plain HTTP first to make sure everything is working before adding on the complexity of HTTPS.

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [9 Ottobre 2016, 1:49am UTC](https://meta.discourse.org/t/unable-to-connect-connection-refused-due-to-https-certificates/51276/3 "2016-10-09T01:49:02Z")

</div>

Using let’s encrypt is an easy way to get ssl.

---

<div class="post-metadata">

### Author: ![GregoryMatthews](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/gregorymatthews/32/120656_2.png) [@GregoryMatthews](https://meta.discourse.org/u/GregoryMatthews)
#### Post date: [9 Ottobre 2016, 3:03am UTC](https://meta.discourse.org/t/unable-to-connect-connection-refused-due-to-https-certificates/51276/4 "2016-10-09T03:03:52Z")

</div>

… thanks for your help.

---

<div class="post-metadata">

### Author: ![kirupa](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/kirupa/32/374711_2.png) [@kirupa](https://meta.discourse.org/u/kirupa)
#### Post date: [14 Marzo 2018, 5:06am UTC](https://meta.discourse.org/t/unable-to-connect-connection-refused-due-to-https-certificates/51276/5 "2018-03-14T05:06:56Z")

</div>

I am running into this same issue, To rebuild with plain HTTP, does that require just commenting out the SSL template line in app.yml?

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [14 Marzo 2018, 1:17pm UTC](https://meta.discourse.org/t/unable-to-connect-connection-refused-due-to-https-certificates/51276/6 "2018-03-14T13:17:00Z")

</div>

Yes, but browsers that have visited your site will refuse to connect. You really should use https.

---

<div class="post-metadata">

### Author: ![lucasbasquerotto](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/lucasbasquerotto/32/133376_2.png) [@lucasbasquerotto](https://meta.discourse.org/u/lucasbasquerotto)
#### Post date: [26 Giugno 2019, 11:56pm UTC](https://meta.discourse.org/t/unable-to-connect-connection-refused-due-to-https-certificates/51276/7 "2019-06-26T23:56:10Z")

</div>

For anyone that face it in the future, make sure to not exceed the rate limit of LetsEncrypt:

> [@After initial setup of DigitalOcean droplet, get Refused to Connect error](https://meta.discourse.org/t/after-initial-setup-of-digitalocean-droplet-get-refused-to-connect-error/45002/4):
>
> Just to point out something that happened to me. I used a testing server whose setup is entirely done by ansible, and after I use the site, I destroy it (ansible handles the destruction of the droplets, digital ocean spaces and so on, so that I’m not charged when not using). What happened is that LetsEncrypt have rate limits, and my domain exceeded, so I started receiving the error that the page couldn’t be reached and it was a bit hard to track the reason to the rate limit of certificates (fir…

You can see if it was exceeded in the logs:

`./launcher logs app`

---

<div class="post-metadata">

### Author: ![BoyanXu](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/boyanxu/32/170548_2.png) [@BoyanXu](https://meta.discourse.org/u/BoyanXu)
#### Post date: [20 Febbraio 2020, 9:24pm UTC](https://meta.discourse.org/t/unable-to-connect-connection-refused-due-to-https-certificates/51276/8 "2020-02-20T21:24:17Z")

</div>

Ho ricevuto esattamente lo stesso messaggio da Chrome.

Nel mio caso, diverse configurazioni erano state impostate in modo errato: alcune erano impostazioni di Discourse, altre riguardavano la configurazione del server di hosting. Publico qui la mia checklist come riferimento per voi:

1. Controlla /var/discourse/containers/app.yml

(Segui questo post: [Allow SSL / HTTPS for your Discourse Docker setup](https://meta.discourse.org/t/advanced-setup-only-allowing-ssl-https-for-your-discourse-docker-setup/13847) )

Assicurati di permettere sia https che http (apri la porta 443, decommenta la configurazione del template relativa a SSL e le configurazioni correlate a Let’s Encrypt), oppure consenti solo richieste http (blocca la porta 443, commenta la configurazione del template relativa a SSL e le configurazioni correlate a Let’s Encrypt).

Se sono state apportate modifiche a `app.yml`, esegui `./launcher rebuild app` per attivare le configurazioni aggiornate.

1. Esegui `./launcher logs app`.

Se hai fallito frequentemente nel ricostruire un server Discourse funzionante, come è successo a me, potresti aver richiesto troppe credenziali Let’s Encrypt nello stesso momento, superando il loro limite.

In tal caso, l’esecuzione di `./launcher logs app` stamperà un `json.` che include un errore 429.

1. Controlla le impostazioni del tuo `Security group` per l’istanza del server ECS

Nel mio caso, il `Security group` è semplicemente un insieme di porte autorizzate (ad esempio, 80 HTTP, 443 HTTPS), che ti consentono di controllare il traffico del tuo server verso l’esterno.

Assicurati di permettere le porte necessarie per ospitare Discourse.

1. Controlla le impostazioni del firewall

Nel mio caso, il passaggio 3 non ha aperto le porte richieste. Si è verificato un problema con le impostazioni del mio firewall.

È strano che non avessi mai configurato il firewall per il mio server, ma quelle porte sono state effettivamente aperte dopo aver eseguito:  
`apt install firewall-cmd`  
`firewall-cmd --permanent --add-port=20-21/tcp` (… e le altre porte)  
`firewall-cmd --reload`

Puoi verificare lo stato delle porte aperte per il tuo dominio utilizzando alcuni servizi online.

---

<div class="post-metadata">

### Author: ![Jack51](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jack51/32/201652_2.png) [@Jack51](https://meta.discourse.org/u/Jack51)
#### Post date: [1 Gennaio 2021, 7:44pm UTC](https://meta.discourse.org/t/unable-to-connect-connection-refused-due-to-https-certificates/51276/9 "2021-01-01T19:44:51Z")

</div>

Ho avuto lo stesso problema: limite di frequenza superato per i certificati.

Risolto seguendo il tuo passaggio n. 1 (commentando i 2 modelli SSL in app.yml) e aprendo il sito in un altro browser dopo la ricostruzione.

Presumo che potrò riattivare SSL dopo che sarà passata una settimana.

---

<div class="post-metadata">

### Author: ![AshNazir](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ashnazir/32/221624_2.png) [@AshNazir](https://meta.discourse.org/u/AshNazir)
#### Post date: [22 Maggio 2021, 10:57pm UTC](https://meta.discourse.org/t/unable-to-connect-connection-refused-due-to-https-certificates/51276/10 "2021-05-22T22:57:00Z")

</div>

Sei riuscito a collegarti dopo una settimana?
