• Members 6 posts
    April 17, 2019, 9:05 a.m.

    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.

  • April 17, 2019, 11:26 a.m.

    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.

  • Members 4 posts
    April 17, 2019, 3:21 p.m.

    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.

  • Members 6 posts
    April 17, 2019, 5:37 p.m.

    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:i.imgur.com/jH8vQXy.png

    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.

  • April 17, 2019, 7:53 p.m.

    Are you sure that docker services are up and running? docker stats will show you list of running droplets.

  • Members 6 posts
    April 17, 2019, 9:25 p.m.

    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     7
  • April 17, 2019, 9:31 p.m.

    This 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?

  • Members 6 posts
    April 17, 2019, 9:35 p.m.

    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.imgur.com/wNF6sNp.png

  • April 17, 2019, 9:50 p.m.

    I see two issues:

    1. Your site is no longer reachable over the domain (it has to for HTTPS to work). You are seeing 503 error because misago-docker is configured to don't handle the requests made over the IP address.
    2. Your HTTPS certificate is rejected by browser. One of things to keep on mind is that restarting misago-docker too many times will hit the ratelimit on Lets Encrypt.

    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. ;)

  • April 17, 2019, 9:52 p.m.

    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.

  • Members 6 posts
    April 17, 2019, 9:57 p.m.

    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
    
  • April 17, 2019, 10:13 p.m.
  • Members 6 posts
    April 17, 2019, 10:42 p.m.

    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.

  • Members 4 posts
    May 19, 2019, 12:39 a.m.

    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?

  • May 19, 2019, 1:57 a.m.

    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?

  • Members 4 posts
    May 19, 2019, 2:31 a.m.

    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:

    SSL Cert

  • May 19, 2019, 3:57 a.m.

    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).

  • Members 4 posts
    May 19, 2019, 4:23 a.m.

    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).

  • Members 4 posts
    May 19, 2019, 6:11 a.m.

    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