On Thu, Jul 13, 2023 at 04:43:42PM +0200, Cyborg via Exim-users wrote:
> >> "TLS error (SSL_read): error:0A000412:SSL routines::sslv3 alert bad
> >> certificate"
> > This is the correct log message.
>
> If the chain of events is like we expect it to be, that the client tries
> to validate the cert , fails and is sending an meaningfull errorcode to
> the server and then closes the connection, wouldn't it be wise to add a
> hint to the reported error message, that it came from the client?
The hint is there, an "ssl alert" is *always* a signal from the other
end of the SSL (i.e. TLS) connection.
It is just that familiary with the concept of an "SSL alert" (TLS alert)
is perhaps limited to those who've had cause to read the protocol
specifications, and may be lost on most users.
> I have to admit, that i was shocked to see this message en mass in the
> log files and instantly checked the local certfiles for a cause. Now,
> after investigating this further, it's clear, that the other side sends
> a corresponding errorcode and openssl creates this messagetext which
> exim just prints out.
Yes, that's what "SSL alert's are". They are a part of the control
plane signalling of the TLS protocol.
> And heres the tricky question: would a new admin, that has never read
> this message list, would conclude, that this message is caused by the
> client, or would he/she try to analyse a local problem that does not
> exist? Seen in this light, a small change to the log message, can't hurt.
The log message is not created by Exim, it is created internally by the
OpenSSL library. Exim just prints the error stack when the handshake
fails. It may be possible to specifically recognise SSL alerts on the
error stack, and augment their output format, but few applications do
this.
Yes, you're not the first MTA administrator who did not realise that SSL
alerts are reports of a problem from the perspective of the remote
client.
Perhaps the OpenSSL library could change the message to be:
"TLS fatal alert from <peer|client|server>: bad certificate"
OpenSSL knows whether it is playing the client or the server rôle, so
knows what to call the other end of the connection, "peer" could be used
if perhaps tricky to make the message include that context at the point
at which it is generated.
--
Viktor.
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
