Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
For more information and upcoming events around #dominoforever, please visit our Destination Domino Page
Hi.
I'm now facing the same problem, with O365. As they are the kind of that world...
Regards
Microsoft just answer us about the fact that our domino is not correctly sending mails to an inbound connector in Exchange Online that is supposed to check our certificate:
"Sending a DN List is not mandatory
The Server DN List is an optional TLS handshake field (per RFC 5246 - TLS 1.2).
Many SMTP servers do not send a DN List because the client should already know which certificate to present.
In mutual TLS (MTLS) scenarios, the server typically only requests a certificate without sending a DN List."
As you can read about the Microsoft answer: they do not send a DN list (even if the connector is about checking a certificate).
And as Domino do not submit the certificate for the StartTLS session, we are facing a lose/lose situation.
Any way to force domnio to present a certain certificate from certstore (we only have one in our certstore) to be able to send mail securely to Microsoft 365 ?
Domino is correctly following the RFC definition.
In this idea, you are requesting Domino to (blindly) submit all(!) certificates available even if they dont match the target.
This is the first time I've seen this request but doing all of that matching in a keyring file based environment - it would be extremely difficult to implement.
So do not expect this functionality to be changed anytime soon.