RAK7240 Basic Station Mode w/Self-Signed IP Certificate

LPWAN Industrial Gateways / Concentrators
1

Hello all,

I have a RAK7240 Wisgate Edge Prime and a self-hosted instance of The Things Stack running on a private LAN, both on the same subnet: 10.1.x.x:

  • The Things Stack: 10.1.200.1
  • RAK7240: 10.1.200.2

I am using a self-signed server certificate for my instance of The Things Stack with the following parameters (I have no internal DNS and so must use IPs):

  • CN: 10.1.200.1
  • Subject Alt Name: IP:10.1.200.1

This certificate is confirmed working with The Things Stack services and I am able to connect my RAK7240 to The Things Stack using Packet Forwarder Mode. However I am unable to connect using Basic Station Mode.

I have followed the instructions to configure LNS, adding my internal CA certificate in the trust field. However when I save and check the logs I see the following:

Thu Sep  9 14:10:30 2021 user.info basicstation[32761]: [any:INFO] /var/etc/station/tc.trust: 
cert. version     : 3
serial number     : 6F:D2:11: ...
issuer name       : CN=myorg
subject name      : CN=myorg
issued  on        : 2021-09-07 05:54:31
expires on        : 2031-09-05 05:54:31
signed using      : RSA with SHA-256
RSA key size      : 2048 bits
basic constraints : CA=true
key usage         : Key Cert Sign, CRL Sign
Thu Sep  9 14:10:30 2021 user.info basicstation[32761]: [AIO:INFO] tc has no cert configured - running server auth and client auth with token
Thu Sep  9 14:10:30 2021 user.info basicstation[32761]: [TCE:INFO] Connecting to INFOS: wss://10.1.200.1:8887
Thu Sep  9 14:10:30 2021 user.info basicstation[32761]: [AIO:INFO] TLS server certificate verification failed: The certificate Common Name (CN) does not match with the expected CN
Thu Sep  9 14:10:30 2021 user.info basicstation[32761]: [TCE:INFO] INFOS reconnect backoff 30s (retry 3)

I have triple-checked and the server certificate is correct, matching the URL of wss://10.1.200.1:8887 as per the CN and SAN above. Is there any reason that the basicstation CN matching/verification might be failing here? Could it be because using an IP as a CN is unusual and the check is expecting a domain? From what I understand using an IP is valid as long as a SAN with IP:<ip_address> is defined.

Any help would be greatly appreciated because at the moment I’m forced to regress to Packet Forwarder Mode.

2

Hei @amorphic ,

Can you post a screenshot of the config page in the RAK7240?

Regards
Vladislav

3

No worries Vladislav…

RAK7240_config
RAK7240_config1890Ă—1788 269 KB

4

Not sure if it helps, but try removing text "Bearer " from the token field.

5

Please check port 8887 is enabled on your server

6

Thanks John.

I’ve tried various combinations:

  • <token>
  • Authorization: <token>
  • Authorization: Bearer <token>

Regardless I encounter the same TLS server certificate verification failed error.

The error text leads me to believe that the problem is related to the certificate verification process rather than authentication.

7

Thank Georgie. Port 8887 is open and TTS is listening on it.

The error text leads me to believe that the problem is related to the certificate verification process rather than TCP connection.

1 Like
8

I am experiencing a similar problem. I am using the following configuration:

image
image626Ă—540 18.5 KB

Product: RAK7249
Model: WisGate Edge Max
Configuration/Setup: basic station, LNS Server, Auth with server and client token (TTN V3), WisGateOS V1.2.2

Strangely enough, I see the gateway sending status to TTN:

image
image1589Ă—528 21.2 KB

However, I see no data from end devices. Not even in the tab “LoRaWAN Packet Logger” from the gateway

9

I also have this problem when I try to connect to a local hosted The Things Stack network server.

10

Follow this section to learn how to connect to The Things Stack Network Server using this mode.

To configure the gateway to use LNS or CUPS, first navigate to LoRa Network → Network Settings → LoRa Basic Station.