First, I want to say thanks for the docs as it gets someone still new to server administration (like me) up an running fairly confidently on a VPS.
That said, I seem to be having trouble with the LetsEncrypt SSL certificate being accepted by browsers. The problem being that it's self-signed.
I'm not sure if this is related, but I also can't login to the admin panel. I'm getting a warning about browser cookies being disabled, but I tried 3 different browsers with the same result.
What you are describing appears very weird. What browsers are you using?
That said, I seem to be having trouble with the LetsEncrypt SSL certificate being accepted by browsers. The problem being that it's self-signed.
This shouldn't happen. LetsEncrypt certificates are backed and verified by browser vendors - that's the part of its magic.
Would you mind showing us how it looks like (the "self-signed" certificate)? That'd be helpful.
Plus, be sure that the certificate could even be generated. For example, in case of using Cloudflare or another CDN, this usually can't happen because of the another IP address.
Yea, sure. Here is the report from WhyNoPadlock.com.
Firefox is giving me a "MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT" error. Here's what the certificate looks like there:
Oddly enough, I can't seem to reach my website by domain name this morning while I had no trouble last night. I restarted my droplet and made sure the domain name records were correct. Can still connect via IP, but I'm getting a 503 error.
Are you sure that docker services are up and running? docker stats will show you list of running droplets.
Domain name resolution seems to be working again.
Here's what I get from 'docker stats' (sorry for formatting. code format doesn't seem to work):
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
afa34f89cb3a misago_docker_misago_1 0.01% 131.4MiB / 1.947GiB 6.59% 103kB / 122kB 53.3MB / 0B 5
67ffd7ed120c misago_docker_nginx-lets-encrypt_1 0.12% 8.266MiB / 1.947GiB 0.41% 88.2kB / 61.6kB 32.2MB / 0B 11
488bea3cbdc5 misago_docker_nginx-proxy_1 0.13% 8.016MiB / 1.947GiB 0.40% 73.2kB / 901kB 25.4MB / 8.19kB 19
76d088799120 misago_docker_redis_1 0.14% 1.848MiB / 1.947GiB 0.09% 14.2kB / 26.1kB 7.25MB / 4.1kB 4
b83c393c8ce0 misago_docker_postgres_1 0.01% 8.887MiB / 1.947GiB 0.45% 67.7kB / 65.1kB 29.3MB / 1.18MB 7This is looking fine. You should be able to access your site, even if without HTTPS.
What domain are you using? Is it one of those something.superspecial TLD's that got introduces over recent years?
Yeah, it's a .estate TLD.
Edit: For what it's worth, I've once set up a Caddy server with this domain and the Let's Encrypt certificate had no trouble going through.
By the way, how are you getting the formatting with light-red background and red text?
Further edit: Not sure if relevant, but I checked the misago.log and got this:
I see two issues:
503 error because misago-docker is configured to don't handle the requests made over the IP address.I've been thinking that maybe firefox takes an issue with your TLD but doesn't seem so.
By the way, how are you getting the formatting with light-red background and red text?
Misago uses markdown for that, but syntax is different for inline code and code blocks. Markdown is also superspecific about block's opening and ending being only content in the line - which is why your original posting didn't format. ;)
That issue is not associated with lets encrypt, but without HTTPS your site will not set cookies so you won't be able to log in. You will see an auth error instead.
I appear to be able to access by domain name, now.
Also, I think this nginx log might be more relevant? At least, I'm seeing an SSL_do_handshake() error, which seems to match the problem:
2019/04/17 05:25:41 [notice] 37#37: signal process started
2019/04/17 05:25:42 [notice] 42#42: signal process started
2019/04/17 05:25:46 [notice] 45#45: signal process started
2019/04/17 05:25:49 [emerg] 66#66: PEM_read_bio_DHparams("/etc/nginx/dhparam/dhparam.pem") failed (SSL: error:0906D06C:PEM routines:PEM_read_bio:no start line:Expecting: DH PARAMETERS)
2019/04/17 05:25:52 [emerg] 86#86: PEM_read_bio_DHparams("/etc/nginx/dhparam/dhparam.pem") failed (SSL: error:0906D06C:PEM routines:PEM_read_bio:no start line:Expecting: DH PARAMETERS)
2019/04/17 05:25:53 [emerg] 106#106: PEM_read_bio_DHparams("/etc/nginx/dhparam/dhparam.pem") failed (SSL: error:0906D06C:PEM routines:PEM_read_bio:no start line:Expecting: DH PARAMETERS)
2019/04/17 05:27:10 [notice] 107#107: signal process started
2019/04/17 05:27:10 [notice] 129#129: signal process started
2019/04/17 05:29:17 [notice] 132#132: signal process started
2019/04/17 05:29:18 [notice] 135#135: signal process started
2019/04/17 05:29:21 [notice] 138#138: signal process started
2019/04/17 05:53:21 [notice] 141#141: signal process started
2019/04/17 05:53:27 [notice] 53#53: signal process started
2019/04/17 05:53:28 [notice] 56#56: signal process started
2019/04/17 05:53:29 [notice] 79#79: signal process started
2019/04/17 05:53:30 [notice] 101#101: signal process started
2019/04/17 05:53:31 [notice] 103#103: signal process started
2019/04/17 05:55:31 [notice] 106#106: signal process started
2019/04/17 05:55:34 [notice] 109#109: signal process started
2019/04/17 05:55:36 [notice] 112#112: signal process started
2019/04/17 05:55:38 [notice] 115#115: signal process started
2019/04/17 05:55:41 [notice] 32#32: signal process started
2019/04/17 05:55:43 [notice] 38#38: signal process started
2019/04/17 05:55:44 [notice] 59#59: signal process started
2019/04/17 05:55:46 [notice] 80#80: signal process started
2019/04/17 05:55:46 [notice] 101#101: signal process started
2019/04/17 06:21:53 [crit] 102#102: *37 SSL_do_handshake() failed (SSL: error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol) while SSL handshaking, client: 165.227.125.110, server: 0.0.0.0:443
2019/04/17 06:21:53 [crit] 102#102: *39 SSL_do_handshake() failed (SSL: error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol) while SSL handshaking, client: 165.227.125.110, server: 0.0.0.0:443
2019/04/17 06:21:53 [crit] 102#102: *40 SSL_do_handshake() failed (SSL: error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol) while SSL handshaking, client: 165.227.125.110, server: 0.0.0.0:443
2019/04/17 06:21:53 [crit] 102#102: *41 SSL_do_handshake() failed (SSL: error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol) while SSL handshaking, client: 165.227.125.110, server: 0.0.0.0:443
2019/04/17 06:26:49 [notice] 33#33: signal process started
2019/04/17 06:26:52 [notice] 54#54: signal process started
2019/04/17 06:26:53 [notice] 75#75: signal process started
2019/04/17 06:26:54 [notice] 96#96: signal process started
2019/04/17 06:41:21 [crit] 97#97: *25 SSL_do_handshake() failed (SSL: error:1417D18C:SSL routines:tls_process_client_hello:version too low) while SSL handshaking, client: 198.108.66.208, server: 0.0.0.0:443
2019/04/17 15:17:37 [notice] 52#52: signal process started
2019/04/17 15:17:52 [crit] 53#53: *4 SSL_do_handshake() failed (SSL: error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol) while SSL handshaking, client: 165.227.125.110, server: 0.0.0.0:443
2019/04/17 15:17:52 [crit] 53#53: *5 SSL_do_handshake() failed (SSL: error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol) while SSL handshaking, client: 165.227.125.110, server: 0.0.0.0:443
2019/04/17 15:19:41 [crit] 53#53: *14 SSL_do_handshake() failed (SSL: error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol) while SSL handshaking, client: 159.65.47.197, server: 0.0.0.0:443
2019/04/17 15:19:41 [crit] 53#53: *16 SSL_do_handshake() failed (SSL: error:1417D102:SSL routines:tls_process_client_hello:unsupported protocol) while SSL handshaking, client: 159.65.47.197, server: 0.0.0.0:443
2019/04/17 15:27:15 [crit] 53#53: *23 SSL_do_handshake() failed (SSL: error:1417D18C:SSL routines:tls_process_client_hello:version too low) while SSL handshaking, client: 184.105.139.70, server: 0.0.0.0:443
2019/04/17 15:37:42 [notice] 33#33: signal process started
2019/04/17 15:37:44 [notice] 55#55: signal process started
GitHub suggests there's a bug in SSL proxy, and there may be other bug with TLS.
There may be solutions for those but I would need to research this to actually understand what's happening here.
Hmm, I see! Well, I may just trash the droplet and start over to see if that resolves anything. Or I'll poke around a bit more to see where the error may be. Either way, looks like Misago is not at fault, here. :)
Possibly I'll try this troubleshooting.
For posterity: My domain name had a DNSSEC record set previously from when I hosted on another VPS, which I realized could be causing problems, so I deleted it. The only issue that seemed to resolve, though, was my inability to access my website by domain name through my work computer. I had been able to access it through my home computer without problem. I also added a CAA record in Digital Ocean, but SSL still seems to be broken.
My saga with network infrastructure continues...
UPDATE : Looks like I just had to wait a bit for the changes to propogate. SSL is now properly configured! Not sure if it was the deletion of the DNSSEC record or the addition of the CAA record. It might be prudent to add that step in the documentation, though.
First time Misago admin here. I followed the instructions at the Misago documentation, and got all the way to the end.
I'm having the same issue as krg had, when I try to log into the admincp page or the normal site without SSL set up properly, I get:
[2019-05-18 15:30:37,804] ERROR Internal Server Error: /api/auth/
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/django/core/handlers/exception.py", line 41, in inner
response = get_response(request)
File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line 178, in _get_response
response = middleware_method(request, callback, callback_args, callback_kwargs)
File "/usr/local/lib/python3.6/site-packages/django/middleware/csrf.py", line 294, in process_view
return self._reject(request, REASON_NO_CSRF_COOKIE)
File "/usr/local/lib/python3.6/site-packages/django/middleware/csrf.py", line 163, in _reject
return _get_failure_view()(request, reason=reason)
File "/usr/local/lib/python3.6/site-packages/misago/admin/views/errorpages.py", line 56, in decorator
return f(request, *args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/misago/core/errorpages.py", line 112, in csrf_failure
return _ajax_error(403, _("Request authentication is invalid."))
File "/usr/local/lib/python3.6/site-packages/misago/core/errorpages.py", line 15, in _ajax_error
'detail': get_exception_message(exception, default_message),
File "/usr/local/lib/python3.6/site-packages/misago/core/utils.py", line 147, in get_exception_message
return exception.args[0]
AttributeError: 'str' object has no attribute 'args'
I've waited a few mintues (nearly 30 at this point) and still don't have a valid certificate, I'll be patient and wait a little longer and see if that helps.
Is there a way to tell if I've hit the rate limit easily? Or will it just manifest as not having a secure site?
Hi!
When you try to log in to admin panel without HTTPS enabled, your browser will not receive CSRF token cookie, and thus won't send it back to Misago when you try to log in. You will get CSRF token error which will cause Misago to crash (this was fixed and is waiting for release).
As for time it takes to activate the certificate, I'm wondering if this time is not extended by time it takes for domain to propagate? Is this newly set domain?
Ah gotcha, that makes sense about the CSRF tokens.
It does appear I have an SSL certificate from lets encrypt now, and visiting https://mydomain.com I get a 500 Internal Server Error.
This is a newly set domain, so it's possible it's just taking a while to propagate. I'll give it a day or two and see if things settle down by then.
FYI here's what ssl checker shows:
If you still have error 500, check files in logs directory for any errors and try restarting the docker containers (there's util for that in appctl).
Tried restarting docker, still get error 500 with https (but works fine with http). Gives an error about the certificate being self-signed but that shouldn't be giving the error 500.
I looked through the logs, and the interesting thing is that there's almost nothing indicating that there are any errors when accessing https. nginx/access.log shows this:
mydomain.com IP - - [19/May/2019:02:12:34 +0000] "GET / HTTP/2.0" 500 595 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36"
mydomain.com IP - - [19/May/2019:02:12:34 +0000] "GET /favicon.ico HTTP/2.0" 500 595 "https://mydomain.com/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36"
Nothing shows up in nginx/error.log (I watched it with tail -f), and nothing shows up in misago.log or uwsgi.log. If I log into the http site though, everything works as expected (can't log in, but we addressed that already).
Ah, it looks like I'm going to have to wait. Got the following message when debugging the Let's Encrypt:
ACME server returned an error: urn:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new authz :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/
For users who are new and want to check this for yourself, I checked this by SSH'ing into the server and running the following two commands:
docker-compose stop nginx-lets-encrypt
docker-compose run -e DEBUG=1 nginx-lets-encrypt
Thanks! Gave me some headaches to find out what's going on... Still not sure how I crossed the limit though. I tested Misago on one test domains.
But anyway at least I know the reason of having error 500 with https ....