<html><head></head><body><div>OK. Time to run rpm -qa on both dev and new and diff the list. Something is missing or diff version on new system.</div><div><br></div><div>Hmm. So the pre-fips connection with tsql worked. That implies it was using md5. Converting the system to fips compliant didn't change the tsql config to use sha1 keys so it still uses (tries) md5. </div><div><br></div><div>Delete the old md5 keys for tsql or remove the package entirely and reinstall (after renaming out the config as conf.old). Do you see keys with creation dates prior to FIPS in /etc/pki?</div><div><br></div><div>On Thu, 2015-08-13 at 14:22 -0400, Adrya Stembridge wrote:</div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 13, 2015 at 12:25 PM, Jim Kinney <span dir="ltr"><<a href="mailto:jim.kinney@gmail.com" target="_blank">jim.kinney@gmail.com</a>></span> wrote:<br><blockquote type="cite"><span style="font-size:12.8000001907349px">The rhel instructions look like the system keys will default to weaker non-FIPS unless fips=1 is a kernel param at </span>at system installation. So <b>converting an existing system won't work</b>. So weak keys with libgcrypt will call for fallback to non-fips but then fails since it's a denied operations mode.<br></blockquote><div><br></div><div>I went through the same steps of activating FIPS on my dev instance, and do not have the libgcrypt error, and am able to tsql to my SQL Server machine. Confirmed FIPS is active and working using the steps written in my initial post to the list. <br><br><br></div></div></div></div>
</blockquote><div class="-x-evo-signature-wrapper"><span><pre>--
James P. Kinney III
Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain
http://heretothereideas.blogspot.com/
</pre></span></div></body></html>