I had a client complain that a friend's ISP mail program was attempting to contact my box and getting the answer:
TLS connect failed: error:24064064:random number
generator:SSLEAY_RAND_BYTES:PRNG not seeded; connected to 69.50.220.235.
This is caused by other mail programs (esp qmail) failing to negotiate a proper TLS connection with the subject box. Articles on the web claimed it was a certificate problem and/or a firewall problem.
Because I had Mailscanner and csf installed by Chirpy's ConfigServer folk, I contacted them to find out if there was a firewall problem or if their MailScanner config had anything to do with it. The answer, which I could have found elsewhere if I had known more exactly what to look for, was to disable Exim from offering to negotiate tls in the first place by putting in the first (override) box of the CPanel Exim config editor the line
tls_advertise_hosts =
When the remote server checks mine, it should not see an offer to talk tls and fall back to a regular conversation. Many thanks to the ConfigServer folk for an answer above and beyond the call of duty--it wasn't their product at fault. [Unsolicited testimonial--everyone should use the ConfigServer products and services. They and their creators are amazing.]
OK, I entered this workaround to jumpstart the proper flow of mail from such servers, but then had a closer look, expecting to find that the tls options had not been properly set up and the initial Exim configuration setting of
tls_advertise_hosts = *
was, somehow, a lie, perhaps not correctly installed on some recent Exim upgrade. However, the Exim config file does correctly contain the lines
tls_certificate = /etc/exim.crt
tls_privatekey = /etc/exim.key
and both of these files are indeed present in the expected places. So, on the face of it, Exim was indeed properly set up for tls.
So, why didn't it work, and does anyone have an actual fix, as opposed to a workaround?
Rick
TLS connect failed: error:24064064:random number
generator:SSLEAY_RAND_BYTES:PRNG not seeded; connected to 69.50.220.235.
This is caused by other mail programs (esp qmail) failing to negotiate a proper TLS connection with the subject box. Articles on the web claimed it was a certificate problem and/or a firewall problem.
Because I had Mailscanner and csf installed by Chirpy's ConfigServer folk, I contacted them to find out if there was a firewall problem or if their MailScanner config had anything to do with it. The answer, which I could have found elsewhere if I had known more exactly what to look for, was to disable Exim from offering to negotiate tls in the first place by putting in the first (override) box of the CPanel Exim config editor the line
tls_advertise_hosts =
When the remote server checks mine, it should not see an offer to talk tls and fall back to a regular conversation. Many thanks to the ConfigServer folk for an answer above and beyond the call of duty--it wasn't their product at fault. [Unsolicited testimonial--everyone should use the ConfigServer products and services. They and their creators are amazing.]
OK, I entered this workaround to jumpstart the proper flow of mail from such servers, but then had a closer look, expecting to find that the tls options had not been properly set up and the initial Exim configuration setting of
tls_advertise_hosts = *
was, somehow, a lie, perhaps not correctly installed on some recent Exim upgrade. However, the Exim config file does correctly contain the lines
tls_certificate = /etc/exim.crt
tls_privatekey = /etc/exim.key
and both of these files are indeed present in the expected places. So, on the face of it, Exim was indeed properly set up for tls.
So, why didn't it work, and does anyone have an actual fix, as opposed to a workaround?
Rick