SOAPwebservice, SSL, many installs

[Wolfgang Orth]

Hello Bruce,

I read through the instructions to create ones own Certificate Authority and Certificates. In your text you refer to regular Webserver and regular Webbrowser.

My intention is to build a Client-Server-combo with SOAP, where both sides are regular Clarion-programs.

However, I assume that this SSL stuff is mostly valid also to this project. But, of course, I still have some questions.

These two Properties are working on SimpleClients, E-MailClients and also  (SOAP)WebClient - right?

DontVerifyRemoteCertificateCommonName
DontVerifyRemoteCertificateWithCARoot

I deducted that from this snippet in the online-manual:

  ThisWebClient.SSLCertificateOptions.CertificateFile = ''
  ThisWebClient.SSLCertificateOptions.PrivateKeyFile = ''
  ThisWebClient.SSLCertificateOptions.DontVerifyRemoteCertificateCommonName = 0
  ThisWebClient.SSLCertificateOptions.DontVerifyRemoteCertificateWithCARoot = 0
  ThisWebClient.SSLCertificateOptions.CARootFile = '.\CARoot.pem

When I set

  ThisWebClient.SSLCertificateOptions.DontVerifyRemoteCertificateCommonName = 1    ! TRUE
  ThisWebClient.SSLCertificateOptions.DontVerifyRemoteCertificateWithCARoot = 1    ! TRUE

then my SOAP-Client does not care whether I have include a common name like wigglediwoop or whatever?

The reason I ask this is, because this combo is to be installed on several different locations, where I neither know any computer name nor the particular IP-Address if the designated Server-machine. But if I understood right, then it doesn't matter, as long as my Client has set DontVerifyRemoteCertificateCommonName and DontVerifyRemoteCertificateWithCARoot to 1.

Right so far?

Problems will appear on the next stage, because other program, from other manufacturers, shall be permitted to access this same SOAPserver with their own programs. And there is very likely a good chance that none of them uses Clarion + Nettalk. It might even be possible that they may access through a webbrowser. That will lead to the problem, that they run into SSL-Errormessages. If that RemoteCertificateCommonName will at least hold the actual IP-Address of the machine, which hosts the SOAPserver, then that error will not appear.

My program will run in Trial-Mode for 30 days, before a licence key is needed.

Now my questions:

1) Would it be a viable solution, to provide a general install to all, where the Certificate has a bogus RemoteCertificateCommonName and later, when the licence-key is sent to the customer, we also send the certificate with the correct IP-Address of the Server-machine?


2) When other manufacterers access our SOAPserver with their own programs / webbrowser, will they be able to suppress SSL-errormessages also? From your manual I know that the webbrowsers can be set up alike (with some work by the IT).

If this is something worth to discuss during the NT-UG-Webinar, you could postpone it until Thursday.

Thanks for your patience!

bye
Wolfgang

[Bruce]

>> then my SOAP-Client does not care whether I have include a common name like wigglediwoop or whatever?

>> Right so far?

yes.

>>  If that RemoteCertificateCommonName will at least hold the actual IP-Address of the machine, which hosts the SOAPserver, then that error will not appear.

I've not made a certificate based on an actual IP address, but I guess it's possible. Another approach is to make the certificate based on the server's name. eg here I go to https:\\hulk and the certificate is set as hulk - although obviously this address only works on the Lan.

>> 1) Would it be a viable solution, to provide a general install to all, where the Certificate has a bogus RemoteCertificateCommonName and later, when the licence-key is sent to the customer, we also send the certificate with the correct IP-Address of the Server-machine?

yes.

>> 2) When other manufacterers access our SOAPserver with their own programs / webbrowser, will they be able to suppress SSL-errormessages also? From your manual I know that the webbrowsers can be set up alike (with some work by the IT).

yes. If, for example, they accessed via a browser then they would need to
a) add your "Certificate Authority" certificate to their browser and
b) either get a certificate from you for "that machine" or add a security exception to the browser to suppress the warning.

we can chat more on Thursday if you like. If you think it sounds like SSL on a LAN is icky, then you'd be right...

Cheers
Bruce