We have an application that auto-generates a certificate and binds it, using httpapi, to a selected port. Under Windows 7, and 2003/2008 Servers this works like a charm. The certificate can also be rebound to other ports by un-binding, then binding to the new port.
Under Windows 8, however, only unbinding from the old port succeeds. An attempt to bind the certificate to the new port value fails with error code 1312 revealing the message "A specified logon session does not exist. It may already have been terminated."
What's odd here is that when trying to add a bound certificate through netsh it also fails, in elevated console, with the same error and message ("SSL Certificate add failed, Error: 1312|A specified logon session does not exist. It may already have been terminated."), regardless to the port number.
To add suspense, the application has an installer that initially binds the certificate on install, and unbinds it on uninstall. And this thing never fails! The installer works in "Windows 7" operating system context, while the application is under "Windows Vista", if this can be a clue. The console is under "Windows 8" context.
Has anyone had a similar problem under this OS? Any ideas why this might be happening?
Any help is highly appreciated, thank you in advance!
In our certificate generating code, we used X509Store class' methods to add the certificate to the store. Under Windows 8 this rendered the certificate "untrusted" even if the application was run as administrator. The cause might be either different implementation of the class in .NET 4.5 or imposed limitations due to the OS context the application was running in.
Solved the problem by invoking "certutil.exe" through a Process class to add the certificate to the store.
Related
We're struggling to get IBM MQ to work across SSL.
We've been provided with the certificate chain for the remote host and installed into the Windows Certificate Store (Local Machine). These all look valid.
We're using the following connection properties:
connectionProperties.Add(MQC.SSL_PEER_NAME_PROPERTY, "other-server.com");
connectionProperties.Add(MQC.SSL_CIPHER_SUITE_PROPERTY, "TLS_RSA_WITH_AES_256_CBC_SHA256"); connectionProperties.Add(MQC.SSL_CIPHER_SPEC_PROPERTY, "TLS_RSA_WITH_AES_256_CBC_SHA256");
connectionProperties.Add(MQC.SSL_CERT_STORE_PROPERTY, "*SYSTEM");
connectionProperties.Add("CertificateLabel", "ibmwebspheremqmywindowsusernamewithoutdomain");
MQEnvironment.SSLCertRevocationCheck = true;
We've established that the "CertificateLabel" is the "Friendly name" in Windows parlance.
We've proven unencrypted communication and network-level configuration.
We're using 8.0.0.7 client.
These are the issues we've come across:
All secure communications fail with a 2538 error. (MQRC_HOST_NOT_AVAILABLE, https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.tro.doc/q045380_.htm)
No success setting the Friendly Name to ibmwebspheremq and ibmwebspheremqmywindowsusername#domain and ibmwebspheremqmywindowsusernamewithoutdomain
General questions:
Are we correct in assuming that we can install generated certificates exclusively in the Windows Certificate Store?
Is the 2538 error even related to SSL communications? It feels like a network error, though there is that final point in the referenced error documentation.
Is there anywhere we can look for more informative error information? eg. relating to the SSL trust chain to see if there is an issue there?
The issue was the following line:
connectionProperties.Add(MQC.SSL_PEER_NAME_PROPERTY, "otherserver.com");
Turns out that:
It needs it in a canonical format, so DN=, etc.
You don't even need that line
Though we did learn a few things along the way:
The line:
connectionProperties.Add("CertificateLabel", "ibmwebspheremqmyusername");
Is the string ibmwebspheremq plus your Windows username (without your domain) and the label should be set on the Friendly name of your client machine's outgoing certificate NOT including the username.
The various folders inside your Windows certificate store are significant. The intermediate CAs should be correctly filed.
When using EppLib.net (and as per the Nominet instructions - http://registrars.nominet.uk/namespace/uk/registration-and-domain-management/registrar-systems/epp/testbed)
In order to verify the identity of the secure server you will need the 'Verisign Class 3 Public Primary Certification Authority' root certificate available free from www.verisign.com (the certificate is also distributed with most web browsers).
I am supplying the Verisign Class 3 PPCA Certs in .crt format (I can't export as a pfx) within the code (and have tried every cert installed on the server).
However each one fails with the error (when trying to negotiate the connection):
An existing connection was forcibly closed by the remote host.
I've confirmed that I can connect from the server to Nominet by running cURL
curl -v https://testbed-epp.nominet.org.uk:700
and that responds as I would expect - or at least without an error!
I have also tried to use the same cert that curl appears to be using without success.
Can anyone help with pointing me in the right direction with the SSL that I should be using or how to get hold of the correct certificate?
thanks in advance
For anyone having a similar issue, it wasn't a question of which SSL certificate to use, but to ensure the correct protocol was being used. Incidentally, I got it working initially using the curl-ca-bundle.crt provided with cURL.
This certificate, in combination with a change to the target .net framework for the EppLib.net project resolved my issue.
On cloning from Github the target was .net 4.0 and Nominet needs at least TLS1.1, which wasn't available in v4.
Therefore I also updated the target to 4.5.1 for the EppLib.net project and changed the SslProtocol from
SslProtocol.Tls to
SslProtocol.Tls12
I have implemented FCM for web using fcm documentation.
Everything'll be fine if I set url like : 'http://xxx' I have no error.
But when I set url : 'https://xxx..', I get error:
"Failed to register a ServiceWorker: An SSL certificate error occurred when fetching the script."
code: "messaging/failed-serviceworker-registration"
"Messaging: We are unable to register the default service worker. Failed to register a ServiceWorker: An SSL certificate error occurred when fetching the script. (messaging/failed-serviceworker-registration)."
Can anyone show me how to fix this error?
This is a general problem when wanting to test service workers in a local development environment without proper SSL certificates. It is not specific to Firebase Messaging but pertains to Service Workers in general.
Here is the solution I found when using Google Chrome: Testing Service workers locally with self-signed certificates
Unfortunately, I don't know yet how to circument the issue with other browsers, but probably there must be similar ways.
For Chrome, you need to start a new instance of Chrome, with some flags telling it to ignore SSL certificate errors for your local origin:
In Linux (and maybe Mac):
google-chrome --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://127.0.0.1 --user-data-dir=/tmp/foo
The https://127.0.0.1 here is the location where your app (and service worker) is hosted locally. You might need to adjust this to use the appropriate port, if serving on a different port than the standard HTTPS port 443, e.g. https://127.0.0.1:3000, when serving your app over HTTPS on port 3000.
The --user-data-dir=/tmp/foo is necessary to start a new instance, with a new user profile, if another instance of Chrome is already running.
In Windows (might vary, depending on where your chrome.exe is):
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost:1123
Again, you might have to adjust the port.
Easier method that worked for me:
Just paste chrome://flags/#allow-insecure-localhost in your chrome browser, and Enable the setting that says something like "Allow invalid certificates for resources loaded from localhost."
A client of mine has trouble with TortoiseSVN. It was working fine till now. She did her last commit on Thursday Feb. 23. 2013 But now she gets the following error:
OPTIONS SSL handshake failed: SSL error: sslv3 alert illegal parameter
She cannot access the Repository anymore. No update, no checkout, no log, etc.
It is difficult to locate the problem. It shows up with tsvn 1.7.4 and 1.7.11
She cannot use tsvn with the ProjectRepository
She cannot use svn commandline client (http://www.sliksvn.com/en/download) with the ProjectRepository
She can use tsvn with a PlaygroundRepository on another Server
She can access ProjectRepository with IE and with Firefox
She can access ProjectRepository with SmartSvn
I can use tsvn in their network with the ProjectServer from my macbook with parallels.
I entirely uninstalled/reinstalled tsvn -no success
I deleted %appdata%\Roaming\Subversion -no success
As an act of desperation, I installed smartsvn which makes her work again, but this cannot be the solution.
It must be the combination of tsvn, her machine and the ProjectRepository/Server. Her Machine works with PlaygroundRepository on another server.
Any Idea is highly welcome. In paticular due to the fact that it worked last week with tsvn 1.7.4.
So the only thing which might have changes is some updates on the windows box.
Check for the installation of MS012-006 on the client. That hot fix broke a lot of things. Roll it back and see if connects are successful.
I'm trying to get WCF to use SSL with ANYTHING for FIVE DAYS now. I've gone through countless walkthroughs, generated more certificates than a mail order diploma company, even tried hot fixes. After working with MS dev tools since VB1, I am now considering flipping burgers as a career option. WCF, as far as I can see, is a complete lemon.
Anyway, to get to my actual question: If I run through this walkthrough:
http://msdn.microsoft.com/en-us/library/ff648840.aspx
I get to step 11 (adding the service reference) and get "There was an error downloading metadata from the address. Please verify that you have entered a valid address".
Details of the error gives: There was an error downloading 'https://localhost/SSL6/Service.svc'.
Unable to connect to the remote server
No connection could be made because the target machine actively refused it 127.0.0.1:443
I'm using VS2008 on Windows 7 with IIS7. I followed the walkthrough exactly (apart from step 5 which was different on IIS7- I went into "SSL Settings" for the VD), so it shows my config (yes I've used httpsGetEnabled and mexHttpsBinding).
Anyone care to save my sanity and job?
EDIT: If I go into IIS, select the VD in content view, right-click on the svc file and browse, I get "Internet Explorer cannot display the webpage". Chrome gives "Google Chrome could not connect to localhost".
IE troubleshooting gives "the remote device or resource won't accept the connection".
If I browse using the IP address rather than using localhost via http, it says that it's secured with https ok. If I browse using the IP and https, I get HTTP error 503. The service is unavailable.
So it looks to me like a DNS issue combined with... something.
When I try to just run the service site project, I get "Unable to start debugging on the web server. Unable to connect to the web server. Verify that the web server is running and that incoming HTTP requests are not blocked by a firewall". I've checked the firewall and it's ok.
Finally cracked it. There were at least three issues at play.
1) A DNS issue of some kind with localhost. It's still unresolved on my machine, but I can work around it by using the IP addy.
2) Another issue may have been that apparently, WCF doesn't work with IIS 7 OOTB. So you need to run command prompt as administrator, and run the following command -
"%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" -r -y
3) After I got through the certificate stuff I was still getting HTTP error 503, "Service unavailable". That ended up being leftovers from my previous attempts, still listening to ports:
http://blogs.msdn.com/webtopics/archive/2010/02/17/a-not-so-common-root-cause-for-503-service-unavailable.aspx
So to get a hello world level service happening with WCF and SSL took me a whole week, and in my travels I discovered many pilgrims who had taken about the same amount of time. Microsoft: You have failed.
Are you using IIS or self hosting? If you're using IIS, it sounds like it's incorrectly configured, because it seems it's not accepting connections on port 443; I guess you're probably missing a protocol binding (https to port 443). There's a detailed discussion of setting up SSL on IIS7 here that might be useful.
Of course, you could easily verify this using the browser, you should be able to connect to the site using SSL from it.
When I have had this error occur, I have found it very useful to run the service from Visual Studio to get additional information. Right-click on the service, and then select Debug -> Start New Instance from the pop-up menu. VS will launch the service using the WcfTestClient.exe.
WcfTestClient will display all the services and endpoints in your service project. A healthy launch will list your services in the a panel on the left, and provide a Start Page tab in a panel on the right. What will happen in your case, however, is that you'll get a list of services in a panel on the top and an "Additional Information" box along the bottom. Your problem service(s) will have a Status of Error.
Click on a problem service in the upper panel, and the Additional Information box will fill with an error message and stack trace. The message will tell you exactly what that problem mex (metadata exchange) address is. That may be enough of a hint for you to solve the problem. If not, post the Additional Information here and I'll be happy to take a look at it.