tomweber-sas
commented
3 years ago Hey @mibret, so it starts:) Sorry, you're the first down this path. So, SSL (TLS) and certificates is an issue only with the HTTP access method. To stat with, saspy has nothing to do with it; it's the HTTPS protocol itself that looks for certificates, wherever it looks (I expect the doc you followed was appropriate), and then tries to verify (by default) the certificate with a CA agency. The certificate provided by Viya, isn't a certificate purchased from a 3-rd party CA agency, so it is not 'verifiable' via those agencies. It IS a valid SSL certificate which means that your HTTPS connection is secure. It's just not a paid for certificate from a CA agency, such that they would 'verify' it's one of theirs (paid for). which has no bearing on it being used and being secure.
So, I (saspy) do default to requesting a verified SSL connection (would have avoided all this, but I wanted to be most secure by default, then back down), and that's where this message comes from, as the Viya cert isn't verifiable. So, I catch that and retry the SSL connection without trying to verify (still TLS!), else this would never work for anyone out of the box. If the Cert wasn't valid to be used for SSL, that would fail, but it is, just not verifiable (paid for from a CA), so it still all works as expected; secure.
You can disable the message, using the supplied Viya certificate, be setting verify:False in you config (then I just get a secure connection w/out attempting to 'verify'). Or you can put a verifiable, purchased Certificate in the search path for HTTPS, and, I guess on the Viya side too; I'm not the expert in this certificate stuff, but I would expect it needs to be on both client and server sides, then it would be verified and still work the same anyway, just without the message.
Does any of that make sense? Hope so. If you have a certificate you can use instead of the provided Viya one, and it can be verifiable, just swap that one in. Else, use the Viya one, and set verify : False and you still have valid secure SSL/TLS interface, but don't get the message about it not being verifiable (cuz it's not; yet still valid).
I can track down someone here with more expertise on this if needed. This is my limited understanding so far. We've run into this here too, with testing, and it's not the most clear and obvious thing even still. It does work as expected, either way, so it's good as far as that goes. It's just a confusing thing when the default Cert isn't a purchased one. And again, I could have ignored it and logged no message, but I want to be the most restrictive by default, which means I'll be getting a lot of these issue once people start trying to connect to Viya.
Thanks, Tom
mibret
We have a customer configuration with a SAS Viya 3.5 environment where it is configured with https/tls. I can make a successful remote shown below, but get the SSL cert error.
$ /apps/anaconda/bin/python Python 3.6.5 |Anaconda, Inc.| (default, Apr 29 2018, 16:14:56) [GCC 7.2.0] on linux Type "help", "copyright", "credits" or "license" for more information.
In looking at the Python docs, it appears I need to add CA root cert and possibly intermediates to the Python cacert.pem. Python shows this default location
Python 3.6.5 |Anaconda, Inc.| (default, Apr 29 2018, 16:14:56) [GCC 7.2.0] on linux Type "help", "copyright", "credits" or "license" for more information.
or
$ /apps/anaconda/bin/python -m certifi /apps/anaconda/lib/python3.6/site-packages/certifi/cacert.pem
I added the CA root and SAS Viya server cert (customer's chain) to the cacert.pem in the above path and still get the SSL error. I am trying to understand what I am missing in the setup? Also, I was trying to see if I can set a python env var / python startup / config file to change the default location to another path for this cacert? I am thinking if the python packages get upgraded, the updated cacert version could be overwritten loosing the custom certs added.
Is that even possible?