Troubleshooting a local Moonshot service

This flowchart illustrates a general troubleshooting flow of a local Moonshot service.

Your first step should be to check that all Moonshot software is correctly installed and configured.

See Install Moonshot Libraries on a Server first. Then see Configure a Linux Server to Connect to an RP Proxy.

Your next step should be to test the local GSSAPI connection.

Does your local GSSAPI connection work?

If your local GSSAPI connection works, then the problem is with your local service-specific configuration.

You should resolve this next.

If your local GSSAPI connection does not work, you should check your RADSEC connection:

Switch to the user that your service runs as (e.g. user 'apache', 'radiusd', 'freerad', 'www-data', 'ssh'):
```
$ su - --shell=/bin/bash [your service user]
```
Does /etc/radsec.conf exist and can you read it?
```
$ cat /etc/radsec.conf
```

Can you read the three certificate files as the user that your service runs as?

$ cat /location/of/ca.pem
$ cat /location/of/client.pem
$ cat /location/of/client.key

Have the certificates expired?

$ openssl x509 -enddate -noout -in /location/of/ca.pem
$ openssl x509 -enddate -noout -in /location/of/client.pem

Are you using the correct certificates? Check that you are referring to the correct CA and client certificates on the local service, and obtain a copy of the server certificate of the RP Proxy to verify against the CA:

This is important when you receive error 14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (tcp.c:235)
```
$ openssl verify -CAfile /location/of/ca.pem /location/of/client.pem
$ openssl verify -CAfile /location/of/ca.pem /location/of/server.pem
```

If your local RADSEC configuration is incorrect, then resolve this issue by following the steps of Configure a Linux Server to Connect to an RP Proxy.

Add your service's local user to the group that has access rights to /etc/radsec.conf and the three certificate files. If necessary, create a group and assign the appropriate rights.

Then re-test your local GSSAPI connection.

If your local RADSEC connection is correct, then attempt to make a connection to the RP Proxy specified in the local RADSEC configuration.

You can test this by connecting to the local RADSEC proxy:

$ telnet rp-proxy.host 2083

If the connection was successful, you should have a Telnet prompt.

At this point, the problem lies in the RP Proxy configuration. Check your local RP Proxy configuration next.

If the connection was unsuccessful, the problem lies in the connection between your local service and the RP Proxy, but not with the RADSEC connection itself.

You should check whether any firewalls exist first, both locally on the service as well as between the service and the RP Proxy. You should check your local RP Proxy configuration next.