Intermittent error using Twilio SMS example

[CaseyR]

Hi, Bruce

I am adding SMS notifications to a solution starting with Twilio.  Got the example working fine.  Put it in my solution where it also worked. Until it didn't. At that time, the example also failed with the same message.  A day later the both started working again.  And now, they are both out again with this error message:

"NET ERROR: The Remote TLS Certificate's Common Name () does not match the Server name (localhost). And so the connection failed to open"

All the message and connection parameters are hard coded for testing to avoid typos, so it isn't input changes.  Twilio's servers responded to direct URL requests and I can't imagine their servers being down that much.

Any suggestions?

On a related matter. Is sms.capesoft.com fully functional now?  Can end clients subscribe instead of NT developers?  I really don't want to get involved with small monthly billings.

Thanks a lot.

[CaseyR]

For those encountering a similar error, the fix is to put

net.SSLCertificateOptions.DontVerifyRemoteCertificateCommonName = TRUE

before the net.post.

Also, I replicated the same problem using the web client procedure in the demo.app example.

[Flint G]

Hi Casey,

I don't believe Bruce has managed to get Subject Alternative Name (SAN) checking into NetTalk, yet.  I suspect what you were running into is one of the servers that Twilio uses to receive requests could potentially have a certificate where the Fully Qualified Domain Name (FQDN) used to reach Twilio is listed as a SAN of a larger certificate, rather than the Common Name (CN), or primary FQDN, on the certificate.  Most browsers won't complain all that much as long as the FQDN it's reaching out to is listed either as the CN, or a SAN, because they have that checking built in.

We'll get there, someday.  Until then, your workaround is the solution.  I prefer to make this toggle an option for the user, so they can decide if they want to accept the implied risk of not checking the CN; but I hate encouraging less secure habits like that.

As for billing for SMS ... FWIW, my personal suggestion would be to simply offer your customers the ability to supply their own access token to the Twilio service, and they buy the service directly from Twilio if they want to use it.  That may not work with your application model, I don't know.  For our SaaS offering, we will provide a "default" configuration that can be overridden by our customers if they don't want to use our supplied configurations, but we pay for the "default" services directly and consider it a cost of doing business.

Regards,
Flint

[Bruce]

Hi Flint,

>> I don't believe Bruce has managed to get Subject Alternative Name (SAN) checking into NetTalk, yet.

I believe it is working in NetTalk 12.

Cheers
Bruce

[Flint G]

Ooh!    Definitely going to try that out...

Thanks for the follow-up!

[CaseyR]

Thanks, Flint.

My intent is to let the end clients subscribe to SMS service (just Twilio at the moment)