Trusted self-signed cert rejected by SMTP client-CodePudding

After failing to get Papercut and SMTP4Dev to work with StartTLS I decided to quickly throw together my own basic "fake" SMTP server; just enough to be able to verify that various applications are attempting to send emails, and so that I can also view their contents. I also knocked up a quick SMTP client to test the server itself. Standard SMTP works great, but I'm struggling to get a secure stream successfully initialized after the client requests it.

I am using a self-signed certificate generated by IIS
It has not expired
It is also present in my personal and trusted CA cert stores
The server is set to ignore CRL check
Both server and client are running on the same machine and are running concurrently via two instances of Visual Studio.

The certificate is found and the server attempts to authenticate with it

server

    private void TlsHandshake(string certSerialNo, SslStream stream)
    {
        X509Store certStore = new X509Store(StoreName.My, StoreLocation.LocalMachine);
        certStore.Open(OpenFlags.ReadOnly);
        X509Certificate2 cert = certStore.Certificates.Find(X509FindType.FindBySerialNumber, certSerialNo, true)[0];

        stream.AuthenticateAsServer(cert, false, false);
    }

client

However as soon as it does the client rejects it and throws an ex

    static void Main(string[] args)
    {
        Console.WriteLine("Starting up...");
        using (SmtpClient client = new SmtpClient("127.0.0.1", 25))
        {
            client.EnableSsl = true;
            client.Send("[email protected]", "[email protected]", "asubject", "abody");
        }
    }

I've trawled through quite a few solutions that helped others in a similar situation, but have come up short. This is the last step the app has to take, so any assistance would be greatly appreciated :)

CodePudding user response：

You are connecting to 127.0.0.1 which I imagine doesn't match the name in the certificate (which needs to be in the Subject Alternative Name field).

You might want to get a certificate in the name of the machine, and then connect using the machine name instead of 127.0.0.1. Connecting to localhost might work, if it is automatically translated as the machine name.

Also, putting a self-cert in the trusted roots doesn't always help: a lot of certificate validators require that the cert is signed by another root. So your best bet is getting a proper certificate for the machine from either a private or public Certification Authority.