search

owntracks / recorder

Store and access data published by OwnTracks apps
Other
877 stars 122 forks source link

Help with ot-recorder and certificates from Let's Encrypt #193

Closed davidsmoot closed 7 years ago

davidsmoot commented 7 years ago

I want to be able to use owntracks and ot-recorder on my server with Let's Encrypt certificates. I had been using a self signed certificate but I got so tired of my Samsung Android phones nagging me with constant notifications warning me of the self signed certificates. So I set up Let's Encrypt certificates and copied them to my Mosquitto directory. I understand I will have to copy the certificates every 90 days and restart Mosquitto but I can live with that.

But I cannot seem to figure out how to get ot-recorder working. Host is Ubuntu 16.04 ot-recorder is built from source version 0.6.9

The part of /etc/mosquitto/mosquitto.conf that matters:

certfile /etc/mosquitto/certs/cert.pem 
keyfile /etc/mosquitto/certs/keyfile.pem

The files cert.pem and keyfile.pem are copied from the appropriate let's encrypt directory along with chain.pem

Here is /etc/default/ot-recorder parts related to encryption:

OTR_CAFILE="/etc/mosquitto/certs/chain.pem"
OTR_CERTFILE="/etc/mosquitto/certs/cert.pem"

I've tried a number of things but I'm out of my depth with troubleshooting this. I know if I comment out the certfile and keyfile lines in my mosquitto conf and comment out the two lines above in my ot-recorder, ot recorder works fine with no TLS. I've tried various options with converting between .pem and .crt, adding a keyfile, and I either get: ot-recorder[8036]: MQTT connection: rc=8 [A TLS error occurred.] (errno=0; Success). Sleeping... or ot-recorder[7672]: Disconnected. Reason: 0x7 [Connection refused: TLS error] I have Googled and looked through these archives without much luck. I did find https://github.com/owntracks/recorder/issues/186 that seems similar but did not want to hijack his thread. These are hosted on the same machine, not in any containers and pointing at the same files and I am testing as root so file permissions are not an issue.

Could someone please help me with troubleshooting this? Thank you, Davdi

jpmens commented 7 years ago

First off, please don't run software (not even our software) as root unless it's explicitly needed. :-) If you're quire sure your file permissions are ok, please also verify that your PEM files actually are PEM. You can do this with openssl x509 -in filename -text -noout for example.

Next, do make sure your OTR_CAFILE contains the whole Let's Encrypt chain, bit of which you'll have to obtain from their site respectively from files provided by them.

One last thing at this point: there's no difference generally between CRT and PEM: both contain PEM-encoded certificates, it's just the file expention whic hdiffers.

davidsmoot commented 7 years ago

I was running the software as root to be able to get access to the files and directories I needed. I realized you are right both about the risk and the fact that maybe running as root is part of my problem. More on that in a second. First answers to your points.

I think maybe you got me a little further but still not yet working.

You said

make sure your OTR_CAFILE contains the whole Let's Encrypt chain, bit of which you'll have to obtain from their site respectively from files provided by them.

So after googling, I found I maybe I was using the wrong pem file.
According to https://community.letsencrypt.org/t/whats-the-ca-file-does-letsencrypt-even-create-one/26430. But using the command syntax you gave me does not seem to support that:

openssl x509 -in fullchain.pem -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:2f:0f:16:53:5d:aa:e2:21:bd:bd:86:e0:64:02:63:f7:96
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
        Validity
            Not Before: Apr 15 23:44:00 2017 GMT
            Not After : Jul 14 23:44:00 2017 GMT
        Subject: CN=<removed for privacy>
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ba:39:71:80:61:ca:d9:4a:8f:7b:78:e4:b6:a5:
                    cb:cd:e2:14:66:8e:92:1f:0e:2d:8b:4a:b3:85:ed:
                    2d:76:1d:2e:36:fc:73:b1:59:92:1d:bd:a6:af:5e:
                    60:bf:bc:8b:c3:e8:41:12:03:a9:cd:e6:34:9b:3a:
                    16:b8:5e:7f:f4:b5:27:d8:0c:5b:59:93:58:68:70:
                    f8:cb:d3:fa:35:5a:03:26:91:11:55:14:72:2d:84:
                    e9:fd:d8:a5:33:1b:e9:62:b0:48:8f:46:4e:ba:9b:
                    99:7a:35:3c:39:04:fc:76:76:6c:64:81:47:4d:a1:
                    b6:8e:0e:a5:89:68:b3:95:43:ad:4b:d6:c7:01:a0:
                    bf:86:79:b1:ed:f2:a6:4e:91:f0:e5:a7:2c:88:e1:
                    6a:50:73:f0:cb:97:c3:67:1d:04:b2:b4:04:23:d4:
                    7a:2b:20:ce:6b:d0:d9:9e:4a:8b:b6:75:4e:0e:91:
                    e5:d4:1d:e2:a2:99:ba:4a:52:35:da:54:19:12:0a:
                    6a:c9:18:9b:f6:05:3c:53:e3:6f:3c:a8:77:f6:5c:
                    c0:21:bc:19:e0:30:14:bc:09:26:79:ec:3d:6e:c8:
                    22:6d:b0:37:8e:08:1d:5b:05:77:0a:d4:14:a5:b5:
                    eb:d2:ee:71:b9:d3:1f:e1:ee:bc:71:e5:ca:10:e2:
                    52:5d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier: 
                4F:7E:5D:8A:75:05:4F:9E:89:20:DE:B4:B3:03:72:49:00:96:8C:CA
            X509v3 Authority Key Identifier: 
                keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1

            Authority Information Access: 
                OCSP - URI:http://ocsp.int-x3.letsencrypt.org/
                CA Issuers - URI:http://cert.int-x3.letsencrypt.org/

            X509v3 Subject Alternative Name: 
                DNS:<removed for privacy>, DNS:<removed for privacy>
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org
                  User Notice:
                    Explicit Text: This Certificate may only be relied upon by Rel

    Signature Algorithm: sha256WithRSAEncryption
         53:42:90:5d:90:8b:de:2d:d6:93:6b:6d:cd:0e:85:a3:f2:8e:
         4a:0a:a9:1f:fe:81:eb:e9:d1:d9:99:16:fc:a7:20:5b:be:fe:
         d2:33:ba:7f:5f:6e:be:openssl x509 -in chain.pem -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0a:01:41:42:00:00:01:53:85:73:6a:0b:85:ec:a7:08
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
        Validity
            Not Before: Mar 17 16:40:46 2016 GMT
            Not After : Mar 17 16:40:46 2021 GMT
        Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:9c:d3:0c:f0:5a:e5:2e:47:b7:72:5d:37:83:b3:
                    68:63:30:ea:d7:35:26:19:25:e1:bd:be:35:f1:70:
                    92:2f:b7:b8:4b:41:05:ab:a9:9e:35:08:58:ec:b1:
                    2a:c4:68:87:0b:a3:e3:75:e4:e6:f3:a7:62:71:ba:
                    79:81:60:1f:d7:91:9a:9f:f3:d0:78:67:71:c8:69:
                    0e:95:91:cf:fe:e6:99:e9:60:3c:48:cc:7e:ca:4d:
                    77:12:24:9d:47:1b:5a:eb:b9:ec:1e:37:00:1c:9c:
                    ac:7b:a7:05:ea:ce:4a:eb:bd:41:e5:36:98:b9:cb:
                    fd:6d:3c:96:68:df:23:2a:42:90:0c:86:74:67:c8:
                    7f:a5:9a:b8:52:61:14:13:3f:65:e9:82:87:cb:db:
                    fa:0e:56:f6:86:89:f3:85:3f:97:86:af:b0:dc:1a:
                    ef:6b:0d:95:16:7d:c4:2b:a0:65:b2:99:04:36:75:
                    80:6b:ac:4a:f3:1b:90:49:78:2f:a2:96:4f:2a:20:
                    25:29:04:c6:74:c0:d0:31:cd:8f:31:38:95:16:ba:
                    a8:33:b8:43:f1:b1:1f:c3:30:7f:a2:79:31:13:3d:
                    2d:36:f8:e3:fc:f2:33:6a:b9:39:31:c5:af:c4:8d:
                    0d:1d:64:16:33:aa:fa:84:29:b6:d4:0b:c0:d8:7d:
                    c3:93
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            Authority Information Access: 
                OCSP - URI:http://isrg.trustid.ocsp.identrust.com
                CA Issuers - URI:http://apps.identrust.com/roots/dstrootcax3.p7c

            X509v3 Authority Key Identifier: 
                keyid:C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10

            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.root-x1.letsencrypt.org

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.identrust.com/DSTROOTCAX3CRL.crl

            X509v3 Subject Key Identifier: 
                A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
    Signature Algorithm: sha256WithRSAEncryption
         dd:33:d7:11:f3:63:58:38:dd:18:15:fb:09:55:be:76:56:b9:
         70:48:a5:69:47:27:7b:c2:24:08:92:f1:5a:1f:4a:12:29:37:
         24:74:51:1c:62:68:b8:cd:95:70:67:e5:f7:a4:bc:4e:28:51:
         cd:9b:e8:ae:87:9d:ea:d8:ba:5a:a1:01:9a:dc:f0:dd:6a:1d:
         6a:d8:3e:57:23:9e:a6:1e:04:62:9a:ff:d7:05:ca:b7:1f:3f:
         c0:0a:48:bc:94:b0:b6:65:62:e0:c1:54:e5:a3:2a:ad:20:c4:
         e9:e6:bb:dc:c8:f6:b5:c3:32:a3:98:cc:77:a8:e6:79:65:07:
         2b:cb:28:fe:3a:16:52:81:ce:52:0c:2e:5f:83:e8:d5:06:33:
         fb:77:6c:ce:40:ea:32:9e:1f:92:5c:41:c1:74:6c:5b:5d:0a:
         5f:33:cc:4d:9f:ac:38:f0:2f:7b:2c:62:9d:d9:a3:91:6f:25:
         1b:2f:90:b1:19:46:3d:f6:7e:1b:a6:7a:87:b9:a3:7a:6d:18:
         fa:25:a5:91:87:15:e0:f2:16:2f:58:b0:06:2f:2c:68:26:c6:
         4b:98:cd:da:9f:0c:f9:7f:90:ed:43:4a:12:44:4e:6f:73:7a:
         28:ea:a4:aa:6e:7b:4c:7d:87:dd:e0:c9:02:44:a7:87:af:c3:
         34:5b:b4:42d4:16:7b:84:36:3b:60:ab:1a:95:7f:
         07:1e:d4:37:1f:e8:41:87:a1:52:7e:ac:a0:0f:70:58:81:56:
         28:19:6f:d6:48:50:46:23:da:68:f7:fe:b0:82:33:30:76:ab:
         7c:14:c1:bf:87:be:84:5e:c3:e2:12:0b:26:14:39:8e:b9:93:
         73:08:6b:d3:8c:0b:a2:5c:30:d0:92:e3:57:c1:02:70:08:b0:
         56:2d:85:a4:ed:bf:aa:09:a2:e1:8f:a8:c2:f9:47:b0:2b:f2:
         cb:63:58:4a:fb:2d:26:00:e1:bb:27:80:9f:b5:67:27:4f:a7:
         99:d7:0f:c7:1a:09:70:17:00:cb:00:6a:35:72:5f:a7:dc:25:
         20:ba:98:c2:da:1e:e1:16:33:df:b9:ad:60:8a:64:b2:fb:2e:
         6d:85:c5:14:3f:cb:06:f3:14:8b:fd:e3:9e:09:b2:70:29:45:
         62:5b:92:5f:53:09:c4:75:3e:88:7e:7c:6e:ed:e0:82:8a:27:
         98:72:08:e9:5c:3b:73:52:2e:34:32:61:3d:b4:be:11:57:fa:
         1c:19:6b:46

That file appears to establish a chain of trust from Let's Encrypt to my domain. The other choice for OTR_CAFILE is "chain.pem"

openssl x509 -in chain.pem -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0a:01:41:42:00:00:01:53:85:73:6a:0b:85:ec:a7:08
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
        Validity
            Not Before: Mar 17 16:40:46 2016 GMT
            Not After : Mar 17 16:40:46 2021 GMT
        Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:9c:d3:0c:f0:5a:e5:2e:47:b7:72:5d:37:83:b3:
                    68:63:30:ea:d7:35:26:19:25:e1:bd:be:35:f1:70:
                    92:2f:b7:b8:4b:41:05:ab:a9:9e:35:08:58:ec:b1:
                    2a:c4:68:87:0b:a3:e3:75:e4:e6:f3:a7:62:71:ba:
                    79:81:60:1f:d7:91:9a:9f:f3:d0:78:67:71:c8:69:
                    0e:95:91:cf:fe:e6:99:e9:60:3c:48:cc:7e:ca:4d:
                    77:12:24:9d:47:1b:5a:eb:b9:ec:1e:37:00:1c:9c:
                    ac:7b:a7:05:ea:ce:4a:eb:bd:41:e5:36:98:b9:cb:
                    fd:6d:3c:96:68:df:23:2a:42:90:0c:86:74:67:c8:
                    7f:a5:9a:b8:52:61:14:13:3f:65:e9:82:87:cb:db:
                    fa:0e:56:f6:86:89:f3:85:3f:97:86:af:b0:dc:1a:
                    ef:6b:0d:95:16:7d:c4:2b:a0:65:b2:99:04:36:75:
                    80:6b:ac:4a:f3:1b:90:49:78:2f:a2:96:4f:2a:20:
                    25:29:04:c6:74:c0:d0:31:cd:8f:31:38:95:16:ba:
                    a8:33:b8:43:f1:b1:1f:c3:30:7f:a2:79:31:13:3d:
                    2d:36:f8:e3:fc:f2:33:6a:b9:39:31:c5:af:c4:8d:
                    0d:1d:64:16:33:aa:fa:84:29:b6:d4:0b:c0:d8:7d:
                    c3:93
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
            Authority Information Access: 
                OCSP - URI:http://isrg.trustid.ocsp.identrust.com
                CA Issuers - URI:http://apps.identrust.com/roots/dstrootcax3.p7c

            X509v3 Authority Key Identifier: 
                keyid:C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10

            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.root-x1.letsencrypt.org

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.identrust.com/DSTROOTCAX3CRL.crl

            X509v3 Subject Key Identifier: 
                A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
    Signature Algorithm: sha256WithRSAEncryption
         dd:33:d7:11:f3:63:58:38:dd:18:15:fb:09:55:be:76:56:b9:
         70:48:a5:69:47:27:7b:c2:24:08:92:f1:5a:1f:4a:12:29:37:
         24:74:51:1c:62:68:b8:cd:95:70:67:e5:f7:a4:bc:4e:28:51:
         cd:9b:e8:ae:87:9d:ea:d8:ba:5a:a1:01:9a:dc:f0:dd:6a:1d:
         6a:d8:3e:57:23:9e:a6:1e:04:62:9a:ff:d7:05:ca:b7:1f:3f:
         c0:0a:48:bc:94:b0:b6:65:62:e0:c1:54:e5:a3:2a:ad:20:c4:
         e9:e6:bb:dc:c8:f6:b5:c3:32:a3:98:cc:77:a8:e6:79:65:07:
         2b:cb:28:fe:3a:16:52:81:ce:52:0c:2e:5f:83:e8:d5:06:33:
         fb:77:6c:ce:40:ea:32:9e:1f:92:5c:41:c1:74:6c:5b:5d:0a:
         5f:33:cc:4d:9f:ac:38:f0:2f:7b:2c:62:9d:d9:a3:91:6f:25:
         1b:2f:90:b1:19:46:3d:f6:7e:1b:a6:7a:87:b9:a3:7a:6d:18:
         fa:25:a5:91:87:15:e0:f2:16:2f:58:b0:06:2f:2c:68:26:c6:
         4b:98:cd:da:9f:0c:f9:7f:90:ed:43:4a:12:44:4e:6f:73:7a:
         28:ea:a4:aa:6e:7b:4c:7d:87:dd:e0:c9:02:44:a7:87:af:c3:
         34:5b:b4:42

That file above appears to establish trust from the root certificate authority to Let's Encrypt.

So I know I have other problems I need to work on but one at a time. Are either of these files suitable for OTR_CAFILE? Do I need a single file that is a chain from root to my domain?

Thank you for your time.
David

davidsmoot commented 7 years ago

I do believe I found a bug in my floundering to figure this out. I tried to change the storage directory to a folder under my home directory so that I could run without root and not worry about permissions.

I ran the initialize again and it complained that it could not access the default location for htdocs. /var/spool/owntracks/recorder/htdocs is not a directory

I edited the configuration file to set the DOCROOT variable and ran the --initialize again but it appeared to ignore the configuration file and use the compiled in value. I tried setting the variable at the command line but no luck with that either. David

jpmens commented 7 years ago

Regarding the DOCROOT thing: would you please paste the output of ocat -v which will show the active configuration?

jpmens commented 7 years ago

Regarding your certificates: it's very difficult for me to check now as I'm on mobile. Generally, you will concatenate all required PEM certificates in your CAFILE from most significant to least (or was it the other was round ...?) What you want to have is a chain which leads from the root down to the certififcate issue by LE for your domain.

davidsmoot commented 7 years ago 
ocat -v
This is OwnTracks Recorder, version 0.6.9
built with:
        WITH_MQTT = yes
        WITH_HTTP = yes
        WITH_ENCRYPT = yes
        WITH_PING = yes
        CONFIGFILE = "/etc/default/ot-recorder"
        STORAGEDEFAULT = "/var/spool/owntracks/recorder/store"
        STORAGEDIR = "/var/spool/owntracks/recorder/store"
        DOCROOT = "/var/spool/owntracks/recorder/htdocs"
        GHASHPREC = 7
        DEFAULT_HISTORY_HOURS = 6
        JSON_INDENT = "NULL"
        LIBMOSQUITTO_VERSION = 1.4.10
        MDB VERSION = LMDB 0.9.16: (August 14, 2015)
        SODIUM VERSION = 1.0.8
        GIT VERSION = tarball

Thank you for the quick responses. I will try concatenating the pems and see where that gets me. David

jpmens commented 7 years ago

Is that ocat -v run with your modified configuration file? I see defaults for STORAGEDIR and DOCROOT; please double-check would you?

davidsmoot commented 7 years ago

On the docroot issue: I have my configuration file modified to point to:

DOCROOT = "~/owntracks/recorder/htdocs"
OTR_STORAGEDIR="~/owntracks/recorder/store"

And the output of ocat pointing at my configuration file:

ocat -v /etc/default/ot-recorder 
This is OwnTracks Recorder, version 0.6.9
built with:
        WITH_MQTT = yes
        WITH_HTTP = yes
        WITH_ENCRYPT = yes
        WITH_PING = yes
        CONFIGFILE = "/etc/default/ot-recorder"
        STORAGEDEFAULT = "/var/spool/owntracks/recorder/store"
        STORAGEDIR = "~/owntracks/recorder/store"
        DOCROOT = "/var/spool/owntracks/recorder/htdocs"
        GHASHPREC = 7
        DEFAULT_HISTORY_HOURS = 6
        JSON_INDENT = "NULL"
        LIBMOSQUITTO_VERSION = 1.4.10
        MDB VERSION = LMDB 0.9.16: (August 14, 2015)
        SODIUM VERSION = 1.0.8

Don't spend a lot of time on this, I think I am missing some big picture user permissions / setup issue. The more I work on this, the more confused I become.

davidsmoot commented 7 years ago

The docroot issue appears to be real to me.

If I do an "ocat -v /etc/default/ot-recorder", it will correctly detect and respond to changes in my OTR_STORAGEDIR but will not detect and respond to changes it DOCROOT

It appears to ignore the DOCROOT variable in both the output of ocat -v /etc/default/ot-recorder and when I run ot-recorder. It always tries to use the compiled in path.

Now obviously it is possible and even likely I am screwing up my configuration file but I have triple checked it.

davidsmoot commented 7 years ago

Still not working for me but a little more information. Let's Encrypt gives me three pem files.

  1. cert.pem which establishes trust between the Let's Encrypt authority and my domain.
  2. chain.pem which establishes trust between the root authority and Let's Encrypt
  3. fullchain.pem which is what the name implies and is nothing more than files 1 and 2 concatenated.

One thing that was confusing is the suggestion to use "openssl x509 -in something.pem -text -noout". What I did not realize is that command appears to just parse the first certificate and output. So running that command with cert.pem and fullchain.pem gives exactly the same results.

So I tried going back to my mosquitto and changing its cafile option to "fullchain.pem" and restarting mosquitto. My android client still works but still no joy on ot-recorder.

I'm starting to think I am jumping to the wrong conclusion here about the root cause of the problem and maybe I need to take a step back with debugging this issue.

Is there another mosquitto client I could use to validate I am using the correct CA file and maybe isolate my problem a bit more?

David

jpmens commented 7 years ago

An MQTT client you can use is mosquitto_sub. For example (to a Lets Encrypt protected TLS site)

mosquitto_sub -h hostname -p 8883 --cafile /Users/jpm/tmp/mqtt/le-all.pem -v -d -t '#'

and le-all.pem contains all the root CA stuff for Lets Encrypt. Since all the data (certificates) it contains are public I'll show you what it contains: https://gist.github.com/jpmens/211dbe7904a0efd40e2e590066582ae5

jpmens commented 7 years ago

You're invoking ocat with a file name; it doesn't support that for the config file, so what it's showing you are defaults compiled in (at time of building). In particular its configuration file is defined as CONFIGFILE in config.mk.

jpmens commented 7 years ago

I'm sorry you're having such a lousy time getting this to work. In particular I have to apologize for leading you up the garden path: I've just checked: DOCROOT is not configurable in the defaults; it's a build-time option from config.mk. (The assumption being it's only needed once per system.). If you think it ought to be a runtime configuration please open an issue, and I'll gladly address it.

jpmens commented 7 years ago

Using the above le-all.pem file I can easily configure ot-recorder to access a correctly configured Mosquitto server protected by Let's Encrypt. This is how I do it:

#!/bin/sh

export OTR_USER="username"
export OTR_PASS="password"
export OTR_CAFILE="/path/to/le-all.pem"

ot-recorder --host mosquitto.example.org \
            --port 8883 \
            "owntracks/#"

That should work for you. If it doesn't, it's probably a mis-configuration on the broker side.

davidsmoot commented 7 years ago

So when I run the mosquitto_sub command with my server name and pem file, I get the same TLS error. So whatever mistake I have made has nothing to do with a flaw in ot-recorder. Something is wrong with how the broker is set up (but Android is OK with the config).

Could you share how you configured the broker with your successful LE test?

davidsmoot commented 7 years ago

I think you solved my problem sir by correcting my ignorance. I just got past the "TLS error has occurred" and am logging points.

My mistake was not understanding how deep the chain should be. Let's Encrypt creates a file in my install called "fullchain.pem" which apparently does not mean the full chain from Let's Encrypt to root.

The final solution was clicking on your le-all.pem link that showed me how deep it should go. Copying your le-all.pem file to my disk and pointing to that and everything worked.

I do appreciate your patience with my ignorance. Thank you. David

davidsmoot commented 7 years ago

Few more notes from a novice setting this up that might help someone. The service file had to be modified for me. It assumed I had a user on the system called owntracks and it also had the wrong path to the binary. When I built from source and did a make install, my binary was at /usr/local/sbin/ot-recorder and the service file had /usr/sbin/ot-recorder.

I'm not getting the web interface working yet (it was working earlier when I had disabled TLS) so I am sure it is my fault. Should ot-recorder --initialize put any content in the htdocs folder? What user / permissions does the built in web server expect for its built in webserver?

David

jpmens commented 7 years ago

--initialize sets up the STORAGE directory only; it doesn't populate docroot; that step is done during a make install, and it basically just copies docroot/* recursively to your docroot.

jpmens commented 7 years ago

I'm glad you got TLS working. If it's any consolation, and this comes from somebody who's no n00b at TLS certificates, I think we've all fallen into LE's fullchain trap.

jpmens commented 7 years ago

This is how I configure my Mosquitto broker with LE certificates:

listener 8883
cafile /etc/acme/certs/hostname/fullchain.pem
certfile /etc/acme/certs/hostname/cert.pem
keyfile /etc/acme/private/hostname/privkey.pem
davidsmoot commented 7 years ago

Copied the docroot again (I had erased it when troubleshooting) and now the webserver is working fine. As far as I can tell, I am fully functional. Thanks again.

I should probably create a minimally privileged user to run ot-recorder instead of running it as my own user but that should be easy. Thanks again.

begleysm commented 5 years ago

This thread helped me but still left me a bit confused. Perhaps some clarification will help others.

I, like @davidsmoot tried putting every .pem file that LetsEncrypt provided into the OTR_CAFILE and always got a TLS error trying to connect to my Broker. @jpmens file le-all.pem worked like a charm as the OTR_CAFILE.

I took a quick look at the files provided by Lets Encrypt and they don't have the handy comments that le-all.pem has. I understand, conceptually, that the files provided by Lets Encrypt don't contain the "full" certification chain. But, what did you do to create the le-all.pem file and/or where did the content come from?

Once I understand it properly I'd like to try adding a blurb to the ot-recorder README.md to clarify how to use ot-recorder with a broker using MQTT certificates.

jpmens commented 5 years ago

le-all.pem is a file which contains the concatenated certificates provided by the Let's Encrypt project. Within the file, as you already mention, are links or mentions to the individual CA or leaf certificates. I got those and then simply added them to the le-all.pem file.

begleysm commented 5 years ago

Ok so I'm working through this. I see that "fullchain.pem" is "cert.pem" above "chain.pem".

The contents of "chain.pem" is the first entry in le-all.pem.

I'm a newb @ how this Chain of Trust works but reading the page @ https://letsencrypt.org/certificates/ basically tells me that

  1. the first certificate (Let's Encrypt Authority X3) says that the server that Let's Encrypt is calling X3 is legitimate and has been validated by IdentiTrust.
  2. The second certificate (Let's Encrypt Authority X4) is their backup server incase X3 goes down (also validated by IdentiTrust).
  3. The third certificate (IdentiTrust root chain) is IdentiTrust saying their own server is legitimate (to prove that their validation of X3 & X4 is legitimate)
  4. The fourth certificate (Let's Encrypt Authority X1) is old and not used anymore (but is validated by IdentiTrust)
  5. The fifth certificate (Let's Encrypt Authority X2) is old and not used anymore (but is validated by IdentiTrust)
  6. The sixth certificate (ISRG Root X1) is Let's Encrypt saying their own server is legitimate

So it sounds like

  1. ot-recorder/the mqtt broker are likely "using" the first and third certificates to prove that cert.pem which is issued by X3 for my server is legitimate thus completing the Chain of Trust.
  2. The second, fourth, fifth, and sixth certificates aren't really being used.
  3. Another, future, solution once Let's Encrypt is verified as a self-signing authority would be to use the sixth certificate along with the "Let’s Encrypt Authority X3 (Signed by ISRG Root X1)" from the page linked above.

And lastly, regarding, the certificate files that Let's Encrypt cert-bot sends down:

  1. fullchain.pem should really be called partialchain.pem as it has my server and Let's Encrypts Intermediary but not IdentiTrust's (or Let's Encrypt's) Root.
  2. A true "fullchain.pem" would have a 3rd certificate at the bottom that was either the IdentiTrust Root Certificate or the Let's Encrypt Root Certificate (depending on whether it was using the cross signed 2nd Intermediary certificate or not)

Does this sound right? I'm trying to learn how this is all working?

f0rdprefect commented 3 years ago

Using the above le-all.pem file I can easily configure ot-recorder to access a correctly configured Mosquitto server protected by Let's Encrypt. This is how I do it:

#!/bin/sh

export OTR_USER="username"
export OTR_PASS="password"
export OTR_CAFILE="/path/to/le-all.pem"

ot-recorder --host mosquitto.example.org \
            --port 8883 \
            "owntracks/#"

That should work for you. If it doesn't, it's probably a mis-configuration on the broker side.

I would really had liked to see this linked from the main docker documentation. IMHO it is quite common to use letsencrypt with basic understanding on how the chain of trust works. So when ot-recorder would not be able to talk to the ssl hardened mqtt server I set up, while the owntracks android app had no problem at all, this left me clueless. Read the documentation over and over again. Then slowly realizing that I need the right kind of cert.

Anyhow with the help of reading this thread I got it all working and am amazed. Thank you for that nice piece of software!

jpmens commented 3 years ago

@f0rdprefect we always welcome contributions to our documentation.

f0rdprefect commented 3 years ago

@f0rdprefect we always welcome contributions to our documentation.

Fair enough. If I find time I can try to contribute. I would try to write sth in the docker-recorder repo...