Ok, so we have a Windows Server 2003 machine with SP2 and both HOTFIX KB 938397 and KB 968730 installed. When we try to use the SHA2 certificates (SHA256) The following things still happen:
• Such a certificate can be imported in the certificate store, but subsequently it becomes apparent that the signature algorithm is not recognized, and that it is denoted as corrupt, with an invalid digital signature; the same certificate imported under Windows Server 2008 is displayed there with “This certificate is OK”.
• If one approaches a webservice that requires SSL with client authentication certificates (as set in IIS) then a call to a webmethod fails if a client authentication certificate of this type is passed along, with error “403 Forbidden”. If with the call a sha1RSA-certificate is passed along, the webservice does return a substantive result. The call is made from .NET-code, framework 1.1, running on the same server.
Does anyone have any experience with this? Microsoft support is slow, and we need this done by 2011-1-1
To everyone who has the same problem:
We've had Microsoft do an extensive search for a solution to this problem, but they could only conclude that these certificates could ONLY be supported by the OS to be used as client certificates. If you install the hotfixes, the certificate can indeed be installed and used in (e.g.) IE. The handshake with a server accepting the specific certificate will work fine. Using the certificate for server purposes (like iis or whatever) will NOT work.
Good luck
Jon,
You might want to check on the cipher suites.
http://msdn.microsoft.com/en-us/library/aa374757(v=vs.85).aspx
Make sure you have them available on your 2003 server.
Related
I just setup MagicDNS and HTTPS on my tailscale account.
Then I ssh'ed into my nas and issued a tls certificate with
sudo tailscale cert "machinename.tailnetalias.ts.net"
Response was:
Wrote private key to machinename.tailnetalias.ts.net.crt
Wrote private key to machinename.tailnetalias.ts.net.key
Now when I try to access the web interface of my nas via https:// in a browser, I get an error. Firefox for example says "SSL_ERROR_RX_RECORD_TOO_LONG".
What can I do about this?
The tailscale cert command doesn't know where the certificate files should be installed (it doesn't even know what you were planning to do with them). So the first question is: did you move those files somewhere to install them? If not, the certificate getting SSL_ERROR_RX_RECORD_TOO_LONG is likely some other cert file which was already there.
If the tailscale cert files did get installed, I think the next step would be to click on the lock icon in Firefox on the left side of the URL. It will have a bunch of information about the TLS connection, in particular:
if the certificate had something wrong with it
in the Technical Details section, it will say what TLS version was used (SSL2, SSL3, TLS1.0, TLS1.1, TLS1.2, TLS1.3).
The SSL_ERROR_RX_RECORD_TOO_LONG error was mostly a problem in older versions of TLS like 1.1 and before. If the TLS version is one of those, it may be necessary to figure out how to get the NAS to stop offering the older versions and only offer 1.2 and 1.3.
I am currently struggling with an issue which I am now led to believe is being caused by IIS.
I am currently testing a self signed PKI setup with a Root CA (MyNewCA), two signed Client Certificates (certificate1, certificate2) and a Revocation list (revocationlist.crl) that is also signed by the CA.
I have added certificate1 to the revocation list and published it to a http port 80 site that exists on our network. I have then created a fake site (testsite) that is secured via a TLS certificate.
From a client machine, I have run the CertUtil commands on both certificate1 and certificate2 and these commands correctly access the http crl site, and recognise that certificate1 is revoked, and certificate2 is a legitimate non revoked certificate.
However, when I connect to the testsite via a client browser, and supply the invalid certificate - IIS still serves me the page instead of giving me a 403.13 error.
I have done a ton of reading, and it seems that at times there are CRL caching issues, however the first revocation list that I published had certificate1's serial number in it, and hence even a cached version will contain that revoked cert.
I have changed the CertCheckMode in RegEdit on the IIS server to the value 4 in an attempt to force IIS to fetch the latest crl on EVERY request, but even that setting is still allowing the revoked certificate to be served to the client.
The CRL itself has;
Effective date of 19th January 2016
Next update of 20th January 2017
I can provide the certutil output if it is useful, or any other log data that would help in pinpointing the problem.
I ran Fiddler on my client machine and verified that the crl was fetched from the Http site.
If anyone can provide any insight into this issue I would greatly appreciate it.
Thanks,
It is expected behavior. IIS do not prevent access to SSL sites even if there are revocation issues with the SSL cert. It is up to client what to do with the information it receives from the server. It is up to client to perform (or to not perform) revocation checking and to make decision about further steps.
In addition, make sure if client's cache has the most recent CRL.
My application requires LWP under SSL, but I can't seem to get it to connect properly without receiving an error.
certificate verify failed)LWP::Protocol::https::Socket: SSL connect attempt failed with unknown error error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed at C:/Perl/site/lib/LWP/Protocol/http.pm line 51.
Whenever I load up the website in FireFox on my server, I receive
This connection is untrusted (Technical error: sec_error_unknown_issuer)
Whenever I load it up in Chrome, it verifies absolutely fine.
I can load the page up in FireFox and Chrome on my computer and receive no SSL verification errors at all.
I have no clue what is different between my PC and my server; they're both using the exact same FireFox versions so I'm not sure why it wouldn't verify properly on there.
I've tried workarounds by putting in $ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0 in the Perl script but it seems to throw the same exact error still.
This is the script I'm using to test HTTPS
Does anyone know any solution to this or any workaround?
I've tried workarounds by putting in $ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0
As the name of the option implies it cares only about disabling the check of the hostname against the certificate. It does not disable the validation of the certificate chain.
Whenever I load up the website in FireFox on my server, I receive ...
Since you get validation errors with Firefox and LWP but not with Chrome, Chrome has probably an additional CA as trusted which they others don't have.
From your code it looks like that you are using Windows and from my understanding Firefox comes with its own CA store, LWP uses Mozilla::CA (which contains the CAs usually shipped with Firefox) but Chrome uses the system CA store. Thus there is probably a CA in the system store which Firefox and LWP don't know about.
While it might be that there is some special esoteric CA which is known to the default Windows CA store but not to Firefox, it is more likely that you are behind some SSL inspecting firewall and that the administrators added the necessary proxy certificate to Windows CA store but not to Firefox or LWP's store. I would suggest you check the certificate chain inside the Chrome browser and look at the top (builtin) certificate.
If you consider the CA trusted you might export it and import it into Firefox. You might also make LWP use this CA by saving it in PEM format and then set the PERL_LWP_SSL_CA_PATH environment variable to point to the saved file or use the SSL_ca_path option in the ssl_opts setting to make LWP use this CA certificate for validation.
If this explanation does not lead to a solution please provide more details about the target URL you are trying to access and the network setup you have, especially if there is a SSL intercepting proxy or firewall. Please provide also information about the version of LWP you are using, because there changed a lot with version 6.
I'm facing a funny issue here.
I got a C# Webforms application running on IIS6. When the user clicks on a certain link, my app makes a REST call to a webservice hosted in the cloud. This call, made by the app running on IIS, fails. We get a WebException, with the message "no response from server".
However, if I try to connect to the same web service, from the same machine, with the same credentials, using SoapUI, the call succeeds. So I guess this means that I can rule out firewall issues, credential issues, and availability of the service.
The code has been tested on numerous other machines (dev, test, staging...), and it worked successfully, so the code itself should not be an issue. I think it's an environmental issue (a setting on web.config or machine.config which prevents outgoing requests).
Any idea as to what that could be?
Thanks!
The reason our REST calls were failing was that we were missing an SSL certificate.
We were trying to make the REST call using HTTPS. The REST service provider's SSL certificate was signed by a well-known CA. However, our server apparently had a hardened build, and the CA's certificate was missing from the certificate repository. Hence, the provider's SSL certificate was considered unsafe.
Sadly, the .Net framework exception had no useful information about this.
We installed the CA's certificate and the issue was fixed.
I have read through this post on signing a PowerShell script with a certificate. This is more on using external certificate from VeriSign (or similar) to encode and protect the code I have developed within a PowerShell script.
I am just trying to find out if this will actually work. I would expect the process to go as:
Purchase code-signing certificate from VeriSign
Install certificate on my computer
Sign the PowerShell script
Execute the script on desired device
Since this script would be signed with a external CA wouldn't Windows be able to authenticate the certificate since Windows trust VeriSign root CA? My guess would be since Windows has the root CA for VeriSign already and trust it, if I happen on a system that does not allow Internet access that the certificate will still be verified and allow me to run it?
That should work. I've never tried it, though, but your logic makes sense.
I looked at the cert store on my Win7 machine and it has an Oracle code signing cert issued by "Verisign Class 3 Code Signing 2010 CA". That CA is an intermediate CA. The root CA is "Verisign Class 3 Public Primary Certification AUthority - G5". That root CA is in Windows trusted root CA store. So what I gather from this is:
That yes you can do it - Oracle does it
Verisign does issue code signing certs, but they are signed with an intermediate CA.
This means Windows has to obtain this cert somehow. The Verisign
intermediate cert does have the "Authority Info Access" field which
is one way Windows can retrieve an intermediate cert. But the
machine would have to be able to access the internet.
An alternative (if internet access isn't available) is to install the intermediate cert on your users' machines. Could be part of an installer. I think that must be what Oracle did on my machine
For an Authenticode EXE, another alternative (if machine can't access
internet) is to make sure intermediate cert was embedded in the
authenticode signature in the EXE. However I don't know if
Powershell would support that.
As another confirmation you could call/email Verisign to verify their support.
Executing the script on desired device still requires you to set the execution policy to at least AllSigned on that device. And you will still get a question if you want to trust this publisher, unless you add the certificate to the device or the domain. See here.