I have configured my old Raspberry Pi 3 recently. I have out some monitoring stuff on it, which are communicates with my main server via https. But my main server using self-signed certificates.
Description of my problem
Basically, I am not an official company who can make “green” certificates. But I prefer to use https even on my local network where I use authorization, so I am using self-signed certificates. These certificates, due to I made them, are signed with warning in software (e.g.: browsers, applications, etc.).
How does it look like? In this output, you can see what is happening when I want to use curl to reach my main server. Curl does nothing because certification is not trustable.
$ curl https://atihome.local:82 curl: (60) SSL certificate problem: self signed certificate More details here: https://curl.haxx.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above.
Curl can be bypassed by using --insecure parameter, but my ticketing application also not possible to contact, due to same reason:
$ HomeTicketCtl -a ListAll Unhandled exception. System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid because of errors in the certificate chain: UntrustedRoot
Of course, there is possibility to programmatically bypass this check, but I decided to simpler set those certificates as trusted certificates.
How can it be done?
It is not complicated. You need to copy the .crt file from that system which store it (in my case where my Apache web server run) to that system which want to reach it (in my case, it is my Pi). File was needed to copy onto /usr/local/share/ca-certificates directory. Then you need to run a command to update the certificates:
$ sudo update-ca-certificates Updating certificates in /etc/ssl/certs... 2 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done.
It is done! After it, those errors above has gone!
Final words
Sometimes, it seems simpler and faster to ignore these errors pragmatically. On this way, I need to remember whenever I issue a new cert for my web server to distribute them which is a disadvantage. But I prefer to make proper documentation about these, so that is not a problem for me.
On the other hand, if I solve it programmatically, I need to solve in case of every single program and application I write and less secured. Thus I decided this method to solve my problem.
