Access https URLs

[VolkerBarth]

Why do I need to provide SSL certificate? I think the best option should be server use certificates from OS. Currently I need to worry with certificates changes and expirations.

[VolkerBarth]

Is your question about web client functions (with URL clauses specified like here) - or generally about SQL Anywhere (or MobiLink) clients with TLS security (i.e. "ENC=tls(trusted_certificates=...")?

[Former Member]

web client functions.

[jeff_albion · Accepted solution]

@Volker, yes there is an OS certificate store. (See: http://msdn.microsoft.com/en-us/library/windows/hardware/ff548653%28v=vs.85%29.aspx )

---

MobiLink clients (SQL Anywhere and UltraLite) do currently support this feature:

http://dcx.sybase.com/index.html#1201/en/mlclient/mc-conparm-s-5989279.html

"For Windows and Windows Mobile, if no trusted certificates are specified, the client loads the certificates from the operating system's trusted certificate store. This certificate store is used by web browsers when they connect to secure web servers via HTTPS."

SQL Anywhere HTTPS web clients currently do not:

http://dcx.sybase.com/index.html#1201/en/dbprogramming/httpclient-choosing-url.html

"Your web client application must have access to the server certificate or the certificate that signed the server certificate to issue a secure HTTPS request. The certificate is required for the client procedure in order to authenticate the server to prevent man-in-the-middle exploits.

Use the CERTIFICATE clause of the CREATE PROCEDURE and CREATE FUNCTION statements to authenticate the server and establish a secure data channel. You can either place the certificate in a file and provide the file name, or provide the entire certificate as a string value; you cannot do both."

---

In summary, neither the "ENC=" SQL Anywhere client TLS connection mechanism, nor the SQL Anywhere database server HTTPS web services client mechanism can currently take advantage of the Windows OS certificate store for client requests. I have also noticed that "xp_startsmtp" also currently cannot take advantage of this certificate store.

I have opened enhancement requests #704014 (HTTPS web service client requests) / #704015 (encrypted dblib clients) / #714322 (SMTP client for "xp_startsmtp") for this feature (being able to use the Microsoft OS certificate store for "trusted_certificates") to be considered in a future release. Thank you for the enhancement request.

[VolkerBarth · Accepted solution]

@Jeff: Thanks for the pointer! - Am I right that IE will use this store (and Firefox may not)?

As to the cited doc: So the feature is supported for ML clients, but not for "ordinary" SQL Anywhere clients? - At least the docs for their trusted_certificates protocol option does not list that default behaviour).

[jeff_albion · Accepted solution]

Am I right that IE will use this store (and Firefox may not)?

Yes, IE actually uses the Windows OS "Certificate Snap-In" when you go to modify its certificate stores - see: http://msdn.microsoft.com/en-us/library/ms788967.aspx for the details.

Firefox has a separate "Certificate Manager" mechanism that it uses to store its own copies of the certificates, so Firefox uses its own information instead of the OS information.

[VolkerBarth · Accepted solution]

Thanks again for the explanations - now it's clear(er) to me:)

Just fitting, I had found out in the meantime from a related article that calling "rundll32 cryptui.dll CryptUIStartCertMgr" will open the same "Windows Certificate Manager" like IE's option dialog does...

[VolkerBarth · Accepted solution]

Could you please tell about the situation of "ordinary SQL Anywhere clients", too?

[jeff_albion · Accepted solution]

So the feature is supported for ML clients, but not for "ordinary" SQL Anywhere clients?

Yes, this is correct. Neither the "ENC=" TLS connection mechanism, nor the HTTPS web services client mechanism can currently take advantage of the Windows OS certificate store. I have opened enhancement requests #704014 (web services) / #704015 (dblib clients) for these features to be considered in a future release.

[Former Member · Accepted solution]

FWIW I've long ago given up on the ASA web (soap?) client and ended up writing my own (private) DLL plugin that leverages WinHTTP to provide similar functionality. It permits HTTPS without knowing the server key (was never able to figure that one out from the documentation, the text above helps a lot here) and also seems to have less problems with timeouts.

I strongly second the suggestion that an enhancement is made for ASA to be able to utilize the web-client libraries provided by the the machine it is installed on.