Trying to script out the deployment of a certificate to a Ubiquiti Dream Machine Pro. I need login, copy the separated cert and key files, then restart the UniFi service. So, I’ve created three tasks. 1) Task Type: Export Certificate, to SSH/SCP the key to /mnt/data/unifi-os/unifi-core/config/. 2) Task Type: Export Certificate, to likewise copy the cert + intermediary to the same location. 3) Task Type: Run…, to execute ‘unifi-os restart’
When I manually run task 1 it told, “Export failed due to connection or file copy failure. Check log for more information.” So I use Google to search on various parts of the log file like “System.Reflection.TargetInvocationException”, “Exception has been thrown by the target of an invocation. —> System.InvalidOperationException”, or “Windows Platform FIPS validated …” however, none of it seemed to apply or help. One person seemed to state success by twiddling a registry bit for FIPS from 1 to 0. Didn’t do anything for me.
Then I saw the save credentials and a “test” button on the settings tab. Works for the Cloudflare DNS API. But not for the UDM-Pro or ESXi login. Those say, “No test available.” Am I missing something simple like tell telling it where PuTTY is? (didn’t see any option to)
2020-08-14 23:10:53.131 -10:00 [INF] ---- Performing Task [On-Demand or Manual Execution] :: Export Key ----
2020-08-14 23:10:53.134 -10:00 [INF] Task [Export Key] :: Task is enabled and primary request was successful.
2020-08-14 23:10:53.350 -10:00 [ERR] SftpClient :: Failed to perform CopyLocalToRemote: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.InvalidOperationException: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.
at System.Security.Cryptography.MD5CryptoServiceProvider…ctor()
— End of inner exception stack trace —
at Renci.SshNet.Session.WaitOnHandle(WaitHandle waitHandle, TimeSpan timeout)
at Renci.SshNet.Session.Connect()
at Renci.SshNet.BaseClient.CreateAndConnectSession()
at Renci.SshNet.BaseClient.Connect()
at Certify.Providers.Deployment.Core.Shared.SftpClient.CopyLocalToRemote(Dictionary`2 files, ILog log)
2020-08-14 23:10:53.350 -10:00 [ERR] Export failed due to connection or file copy failure. Check log for more information.
Hi, you have FIPS enabled and cannot perform certain cryptographic functions. Don’t enable FIPS unless you really know what you’re doing and are prepared to compromise on the range of cryptographic functions your machine can perform.
Right, so just to be clear, this is a stock base install of Windows Server 2016 standard. Prior to trying to solve this problem - I had no idea “FIPS” was a thing. So it is nothing that I consciously or purposefully previously tried to enable. Let alone previously known to exist. However, that is what is in the log out put.
That said, though. I can definitively state that changing the value of “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy” from (1) to (0) breaks my system. [Originally found at 1]. Changing it to 0 breaks my ability to RDP into the server running Certify the Web.
But still, even with the value changed to 0 - I get the same error out put in the log file. So I’m going to leave the reg key value at 1.
[Oops left an early draft of my response at the bottom here - I’ve edited it out]
Thanks, sorry I’ve no idea why it would be enabled on your system.Our app doesn’t touch anything like that, all that happens with FIPS is that when we try to use certain standard cryptographic functions they error on machines with FIPS enabled. The app should detect FIPS on startup and give you a warning?
I don’t think changing the registry key is the correct way to disable the feature, instead it’s using the local system policy editor.
Yea, I’m confused as well. And, No, I don’t get any warning on startup of Certify about FIPS.
But following the article you linked - it shows yes, that “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing” is listed as enabled. Even following the method outlined in your article, though, when I disable it. New RDP connections are disabled. Even if I reboot that server (from VM console, this is a VM, btw) I can’t establish new RDP sessions. I have re-enable FIPS to regain RDP access. I guess the take away is that “FIPS” mode is enabled on my install, however that happened (It sure wasn’t me), and the next steps to try and solve my problem is to try and find out how disable it - without breaking RDP access.
But, I’ll perhaps try certify from other VM first. Because I checked other VMs in my lab setup domain and they do not have “FIPS” enabled and I can RDP to them just fine.
So yea, I’m super confused - and maybe this isn’t the right place for this troubleshooting - but how do I disable the FIPS mode, but still retain functional RDP access? How did it get enabled or why does disabling FIPS (on the one VM - designated as the web server) break RDP access?
I don’t know - and that seems to clearly be stepping outside the bounds of support for Certify the Web. If you can help great, if not that’s ok. This is a low priority issue for me. But, thank you so much for your support so far
The reason it would be difficult for us to support FIPS fully is that we use other libraries (such as the one for SSH/sftp) which in turn may use non-FIPS compliant cryptography.
Not sure if that will update and FIPS settings (that’s around support ‘FIPS approved’ cryptography providers) but it does enable/disable good defaults for supported TLS ciphers and everyone should use it. As an aside, the very first versions of Certify actually had a similar lockdown function built in (to set TLS best practice registry settings) but IISCrypto does it better.
So I’ve returned to this topic and tried it on another computer in the network. It’s what I’ve designated the “admin-PC” for the network and verified that this one doesn’t have that FIPS non-sense going on it it.
With that out of the way - the problem now became that Certify was using SFTP for the SSH (remote) authentication method to upload the cert bundle (.pfx) which my target device doesn’t support. It only support SCP. So I figure out how to use PuTTY scp on the command line and figure I’ll just make a “Run…” task.
Now the first time through - PuTTY scp states, hey I don’t have the RSA key fingerprint on record so I can’t verify who I’m connecting to. But, at the command line, I type “Y” to accept that key and add it to PuTTY’s key cache. Subsequent executions now do not generate that error message.
So create my “Run…” task in Certify, I point Certify to the PuTTY scp .exe file, I copy the arguments and options over, and then save the task. Remember, I already saved the server RSA key to PuTTY’s key cache by first executing these command manually.
However, when I try to execute my “Run…” task in Certify using the commands created using the CLI - Certify hangs and then eventually fails saying it killed the task for taking too long and shows me that PuTTY was waiting for Certify to accept the RSA key of my server.
I don’t know what’s going on. This is the last step I need to get this update process fully automated so I don’t have to manually do anything anymore. I’m just getting frustrated. If it’s running PuTTY scp in isolation of the OS or in someway that means PuTTY can’t get to its keystone … then how do I script or automate pressing the “y” button to accept the RSA key.
whoa … ok omg … so I figured it out there is an option to specify the RSA key manually on the command line. So I just grab the finger print pop it in there. Then add the -batch option to disable interactive prompts, so if the command execution fails, then it fails immediately and doesn’t wait around for user input.
Glad you got it working. Yes, we don’t currently have SCP support, although we likely will have in the future. It’s also pretty important which user the Task is running as especially when private keys etc are involved as the service user may not have access to the required user profile otherwise (if one is required).
Oohhhhhh, that’s probably it. Certify is prolly being run as Admin. And while my account is an administrator - it isn’t the Administrator. So that’s probably why Putty doesn’t have access to it key cache - which it stores in the Windows Registry, per user, I’m pretty sure. Anyway, I’ll likely be able to adapt this to the other network gear in my network.
Because Certify is a Windows service, it runs as the SYSTEM account by default. You can technically change the account globally(in services.msc), which is not supported… or you can run certain tasks as a specific account in the UI.
Ahh, ok - so in Certify, in this case, I could change the task parameters ‘authentication’ to “Local (as a specific user)” and specify my own account. Where I previously thought this was already the case. But, makes sense now that it would me the SYSTEM account.
Again, you all are the best. Super appreciate the insights and help
So having solved the main problem here of setting up automated / ssh delivery of TLS certificates - I went back to this FIPS non-sense stuff and it looks like IIS crypto was previously run on the affected VM server. I noticed that when I downloaded IIS crypto that it was already in the download folder and the version was from 2+ years ago.
This would co-inside with when this network was initially setup and explains why the trouble was specific only to the web server VM. Because at the time I was interested in improving the default web security access to it.
Maybe it was myself or maybe it was a template from IIS Crypto? But it looks like that’s where this FIPS enablement came from.
Anyway, RDP access breaks when cipher Triple DES and SHA-1 hashing is disabled. But, then when FIPS is enabled it works again? Maybe FIPS forces RDP access to a higher encryption standard?
Regardless, I’ve figured out how to disable the FIPS mode and retain RDP access on the VM server that was affected! Thank you all for your support over this past month
