I'm distributing a Raspbian based RPi image, which contacts a webserver through PHP and file_get_contents() on startup. The image was created November 2019, the server certificate is newer, from June 2020.

On a newly flashed image, the connection fails:

PHP Warning:  file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages:
error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed in lib.php on line 83
PHP Warning:  file_get_contents(): Failed to enable crypto in lib.php on line 83

If I run the request in a loop until it succeeds, it works after about 20 seconds. It then keeps working immediately on subsequent boots. To test this, the image was mounted on a different system and only the relevant file edited.

I suspected that CA certs or similar things get updated on startup, but I can not find any changed files related to that. (find / -mtime -1)

Apparently something is different after the first boot, yet nothing is different on the SD card.

Does anyone have any idea what could be causing this?

  • Is it running before networking available? – Steve Robillard Oct 14 '20 at 19:14
  • That was my first thought, too. It's waiting until an IP address is set on eth0 or wlan0. I think the error implies that it has fetched the certificate. The site is contacted through its DNS name, so DNS must also be up already. Also, that wouldn't explain subsequent boots always working. – Mantriur Oct 14 '20 at 20:33
  • 1
    Some cryptographic operations used in some TLS ciphers require seeding of random number generator. If the image is fresh it may not had the chance to gather enough data for seeding the random number generator and hence the request fails. Would be a possible explanation. – Robert Oct 16 '20 at 21:54
  • @Robert Very interesting, thanks. How does that survive a reboot though? – Mantriur Oct 18 '20 at 19:27
  • 1
    I am not an expert regarding initial seeding on Linux, but as far as I know entropy is initially collected e.g. via Ethernet traffic and other sources. That would explain the 20 seconds. Once enough randomness has been collected the current state will be saved before shutdown. But for the real details check the Debian documentation on /dev/random and /dev/urandom. – Robert Oct 18 '20 at 19:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.