Connecting sms gateway to local CHT instance

[mrjones]

Hi @mozzy. I noticed you’ve switched out the certificate on cht.openelis-global.org to be the local-ip.co one:

echo |openssl s_client -connect cht.openelis-global.org:443 | openssl x509 -noout -dates           
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *.my.local-ip.co
verify return:1
DONE
notBefore=Oct 26 07:27:54 2021 GMT
notAfter=Jan 24 07:27:53 2022 GMT

If this is the case, then to remove the TLS errors, you can use https://44-228-97-26.my.local-ip.com as your URL. Note that you should consider this as effectively not having TLS enabled because the private key is intentionally shared.

Otherwise, if you want to go back to the wild card *.openelis-global.org cert issued by InCommon where you had the error - I strongly suspect an issue with your certificate chaining. The Java error that @diana gives me this page discussing the issue, and only #3 " The server configuration is missing an intermediate CA" applies to you as you’re using a valid CA and it isn’t self signed. Another relevant search result was this one, which also points to a chaining issue.

To verify your chain is correct in your container, these are the steps to try:

1. Get a copy of your wildcard certificate in server.pem, a copy of your intermediate chain cert in chain.pem and a copy of your private key in server.key
2. Add the server and chain .pem to the same file: cat server.pem chain.pem > default.crt
3. Copy the newly created .crt into your medic-os container to /srv/settings/medic-core/nginx/private/default.crt
4. Copy the private .key to /srv/settings/medic-core/nginx/private/default.key
5. Restart nginx with: docker exec -it medic-os /boot/svc-restart medic-core nginx

Let us know if that fixes the issue!

CC @craig

[mozzy]

Thanks @mrjones .

@mrjones

If this is the case, then to remove the TLS errors, you can use https://44-228-97-26.my.local-ip.com as your URL.

Yeah. i did that as a quick work round for the mean time ,as i was trying to debug why my certs fail to validate on Android.
so temporalily we use https://44-228-97-26.my.local-ip.co/ and it works fine .

Let me try out the steps above and let you know.

[mozzy]

@mrjones ,
Thats true , when i install back the *. openelis-global.org cert and i try to verify it
i get

depth=0 C = US, postalCode = 98195, ST = Washington, L = Seattle, street = 4545 15th Ave NE, O = University of Washington, OU = UW-IT, CN = *.openelis-global.org
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, postalCode = 98195, ST = Washington, L = Seattle, street = 4545 15th Ave NE, O = University of Washington, OU = UW-IT, CN = *.openelis-global.org
verify error:num=21:unable to verify the first certificate
verify return:1

meaning OPenSSL was unable to verify the certificate’s issuer or the topmost certificate of a provided chain

[mrjones]

@mozzy - Thanks for the update and the confirmation that the error is in the chain. Did you double check that you you added the intermediate cert before copying the default.crt file to the container? Is there another nginix, or any other web server, with this *.openelis-global.org cert that you can compare against?

As well, since this is a server with access to the internet and a DNS entry, you may want to set up Let’s Encrypt certificates for just cht.openelis-global.org - this would bypass any issues you have with the InCommon CA wildcard cert.

[cliff]

@diana

Indeed there’s a typo in the route (/api/v1/sms/radpidpro/incoming-messages) so please

hello @diana

Am trying to integrate rapidpro with cht however am getting

{
    "code": 400,
    "error": "Message was not saved"
}

[diana]

Hi @cliff

Please share API logs to see more details about what is going on.
Alternatively, please share the contents of your POST body.

[cliff]

@diana

Alternatively, please share the contents of your POST body.

thanks @diana

{
    "content":"cht","from":"+256783243994","id":"355fce73-2ce1-428d-aa9a-8123f7eac886"
}

though it keeps on hanging when sending the request

i have also upgraded my CHT instance

[diana]

Hi @cliff
Could you have a look at API logs to see if there are any errors logged?

[mozzy]

@mrjones

Did you double check that you you added the intermediate cert

I had forgoten to reply back , adding the intermediate certs to the certificate solved the issues. Our testing server https://cht.openelis-global.org/ now works fine wtih the Android App

[mrjones]

Great news - thanks for sharing the update @mozzy !

[cliff]

hello @diana

Am attempting to connect to CHT using the webhook in rapidpro
however the posting works fine via postman

But when i try via the simulator i get a failure

Am using

> @(json(object(
>   "id":"1f0c6157-1747-44a1-8138-c26ad3d82e20",
>   "from":"+256 783 243991",
>   "content":"hello cliff"
> )))

[diana]

Hi @cliff

Instances that use the local-ip.co reverse proxy are only accessible in your local network, it’s expected for the textit RapidPro server to not be able to access it.
To make your local instance accessible outside of your local network, you’d need to use a service like ngrok.

[cliff]

hello @diana
i have hosted the CHT Instance on ngrok https://255a-41-210-159-84.ngrok.io/#/messages/contact:89a7aa7c-4240-4016-8982-36e23e26fd1c as you recommended above … When i POST to CHT from rapidpro i get {"code":400,"error":"Message was not saved"}

this is coming from cht-core/api/src/controllers/rapidpro.js at 8f328d40b21dd95a6f24606e19c607c75e8dc41d · medic/cht-core · GitHub though not sure why the message is not being saved

[diana]

Hi @cliff

Can you please check API logs to see if any errors are logged?
From the screenshot you shared, it’s concerning that the content-length header is 0.
I also see an error in the background about invalid json.