How to get Abcpdf to render content over SSL with Self Signed Certificate

Question

Our Dev/QA environments use self signed ssl certificates and we are trialing Abcpdf to convert html to pdf but the site where the html is rendered is run under a self signed SSL certificate.

    Doc theDoc = new Doc();
    theDoc.AddImageUrl("https://mysite/Test");
    theDoc.Save(@"c:\tmp\htmlimport.pdf");
    theDoc.Clear();

results in

WebSupergoo.ABCpdf9.Internal.PDFException : Unable to render HTML. Unable to access URL.
COM error 800c0019. Security certificate required to access this resource is invalid.

The manual states for TimeStampServiceUrl :

ABCpdf uses System.Net.WebRequest to send the time-stamping request. You can use System.Net.ServicePointManager.ServerCertificateValidationCallback to customize trust relationship establishment when you connect to an SSL/TLS channel.

But nothing similar for AddImageUrl(), I have tried anyway and the callback is never hit:

public class PdfTester
{
    public void Test()
    {
        ServicePointManager.ServerCertificateValidationCallback = ServerCertificateValidation;

        Doc theDoc = new Doc();
        theDoc.AddImageUrl("https://mysite/Test");
        theDoc.Save(@"c:\tmp\htmlimport.pdf");
        theDoc.Clear();
    }


    private static bool ServerCertificateValidation(
        object sender,
        X509Certificate certificate,
        X509Chain chain,
        SslPolicyErrors sslPolicyErrors)
    {
        return true;
    }
}

Any ideas how to bypass this validation in this scenario?

Answer 1

Try running this through fiddler, you may be encountering this issue caused by http://support.microsoft.com/kb/2677070

The symptoms of this issue lead you to focus on the target URL, but there may be several sub requests to the windows update URLs listed in that KB article as well as requests to the URL in the certificate. We had this issue, and fiddler was able to expose the 502 errors along the way which resulted in the 800C0019 error.

We fixed it by adding all the URLs exposed by fiddler to the customer's exceptions list, but there is fix from Microsoft here.

Of course this is just a possible resolution.