PSPKI
PSPKI copied to clipboard
PKISolutions
Test-WebServerSSL doesn't return the certificate for some sites
I've got a couple of servers with known valid certificates that can't be verified using Test-WebServerSSL as the certificate isn't returned (neither is a ReturnedUri listed).
Among the servers are SharePoint 2016, Az DevOps Srv 2019 and Qlik.
The Qlik-server does get verified if specifying the FQDN. (The host name only isn't part of the SAN.)
The SharePoint server certificates does NOT have the server machine FQDN-included at all due to security reasons. The DevOps server has the machine FQDN in the SAN-only.
It seems to me that Test-WebServerSSL reuires the ReturnedUri FQDN to contain the same FQDN as the OriginalUri (or at least being present)?
This (older?) version of Test-WebServerSSL works as expected
Test remote web server SSL certificate
The current Test-WebServerSSL in the module presents me only with the Pkcs7Chain and no ErrorInformation or Certificate.
Oh, ok. Just noticed this blog Updated Test-WebServerSSL function (C#)
Seem there's an ongoing issue with the Test-WebServerSSL command?
This command wasn't updated for a long time and don't have plans to fix it. Instead, I will replace this functionality with my another work: https://www.pkisolutions.com/tools/sslcertverifier/. I've added great configuration support and reliability, including PS automation. In next version, new tool will replace Test-WebServerSSL command
OK, great :)
Any chance that the SSLVerifier.Core.dll will be released with a PowerShell module or script instead? I really can't distribute pure binaries the same way as I handle .ps1 modules at my client... :/
Or maybe that is what you mean by replacing?
(Handling external dll:s in a module of my own adds to the overall over head.)
Any chance that the SSLVerifier.Core.dll will be released with a PowerShell module or script instead?
yes, I will add PowerShell wrapper in PSPKI, or release that module as separate package and retire Test-WebServerSSL in favor to that new project.
Handling external dll:s in a module of my own adds to the overall over head
what do you mean? I'm an author and own both, PSPKI and SSL Verifier Tool, so there are no legal issues if you mind them.
what do you mean? I'm an author and own both, PSPKI and SSL Verifier Tool, so there are no legal issues if you mind them.
Yes, I was thinking more in the terms if you wouldn't release it your self as a module... But as you are, that won't be the case :)
I still don't know which option is better. SSL tool is a complete solution, so it is suitable to be shipped as separate module. But PSPKI may suffer if I remove this tool from module. On the other hand, they don't require much efforts in integration in PSPKI.
For automation and CI/CD pipelines, with regards to certificate handing, the PSPKI option is really a must :)
And as long as you don't implement breaking changes in the dll, the PoSH-wrapper will be ok :) But if you update the wrapper along with new features in the dll, I'd happily take that as well.
I simply will mark existing command obsolete and introduce new version with new name. Both versions will be available at same time for at least one release, so customers can migrate from old to new commands and in subsequent releases old command will be removed completely.
Well, you do have the option of using alias parameters. If the new commandos is compatible enough.
I used to rely on this module and this cmdlet. But I too am finding issues with it.
Using v3.5 and testing an endpoint, the first two tries return the certificate. Subsequent tries of the same endpoint do not.
I shelled out $50 for the new application, but that doesn't work very well. I find it gives a green light on sites when run in bulk, but only returns the certificate information reliably if I test a single entry. Using the sample PowerShell with the new DLL doesn't seem to work.
