Access https URLs

[Former Member]

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.

[Former Member]

I believe a server certificate has to identify the domain it is served from. If so, it isn't possible to ship a certificate from a signing authority for use at customer sites.

[Former Member]

But using same logic, you don't send certificate when you use your browser to go to your internet banking. I wanna know why "SA browser" doesn't have same behavior.

[graeme_perrow]

Browsers are shipped with a ton of root certificates built-in. When the browser connects to your bank site, the server sends its certificate to your browser, which checks to make sure that it is signed by one of the certificates it already knows about. SA works exactly the same way, only it doesn't ship with hundreds of root certificates already installed.

[Former Member]

@Graeme, ok. But can SA use root certificates of OS to check current url certificate.

[MarkCulp]

It could, but it does not currently do that. I have had discussions about this in the past and we may consider this as an enhancement in some future release.

[Former Member]

Mark, and do you have a schedule for this?

[VolkerBarth]

Is there really an OS-specific certificate store, or is this browser-specific?

At least when using our company certificates, I surely have to import them in each browser (IE, FF, ...) separately... - and one of our applications makes use of client certificates and - as it is WinINet based - pulls them automatically from IE's store (as IE is WinINet based as well).

[MarkCulp]

Zote: No, I cannot say at this time when this feature would be available.

[graeme_perrow]

I believe there is an OS store that most browsers use, but Firefox has its own. IIRC, Chrome uses the same list as IE does.

[VolkerBarth]

I should correct myself - it's not WinINet but CryptoAPI that is used both from IE and our respective application..

Note Jeff's answer which clarifies this comment question...