As part of a ClickOnce deployment I'm running mage.exe
mage.exe -Sign "manifest file" -CertFile Cert.pfx -Password yepit5right -TimeStampUri http://timestamp.verisign.com/scripts/timstamp.dll
the certificate comes from Verisign in the first place so using their timestamping service.
This works fine on some machines but not others, and they come back with the very readable error code of -2147012865 which translates to error 12031 - ERROR_INTERNET_CONNECTION_RESET.
I can connect out through IE on that machine to sites such as stackoverflow.com and so the proxy settings which it needs appear to be correct.
Does mage.exe support authenticating proxies? This used to work, over a year ago now, before we had a major outbound proxy change which I think included changing from non-authenticating to using integrated authentication at the proxy layer.
Thanks
Not a great answer but it turns out that mage.exe cannot authenticate through to a proxy when making the request out to the timestamping service.
To get around this restriction I have added the source machine and the target URL to our outbound proxy's "whitelist" of requests that are allowed out without requiring proxy authentication. As you could imaging doing this within a corporate environment where the security team own that list was not a simple task, I much prefer cracking the technical nut.
As soon as this was added mage.exe started behaving as expected, and as it behaves in our test environments which have a non-authenticating proxy.
Related
I have been working with web services connecting to URLs provided by different clients and so far it has all been done using one-way authentication. Now I'm asked to enable 2-way (mutual) authentication for one of the clients. I did a lot of research and reading but still confused about a lot of things.
I could test successfully on my local machine following instructions from various different articles. But the problem is now to deploy it in production.
Here's what I did for testing: I created a test Web service Host and assigned it a self-signed certificate and created a client to test this. After this I created a client certificate using makecert and verified that this is installed via MMC. I then modified my Host app to only allow clients with certificate and tested from client to see the connection refused due to not providing the client certificate. Then I modified the bindings in the client application to include the certificate name and I was able to connect to the Host successfully. So this completes local hosting.
Now the real problem. The tech team is going to create a certificate in "cert store" on the server. And I need to test again to make sure everything works as expected. We have a few different developers who all want to test on their machines on their local code. Can we all use the same certificate somehow? I don't think we would be allowed to import the certificate but what suggestions could I give them so all of us can use the same certificate?
I'm also confused about issues like difference between windows certificate and IIS certificate. What advantages would the IIS certificate provide?
Thanks for help!
Edit: Could one of the differences between installing on IIS be so that the hosted sites be accessed via SSL connection? This would mean we don't really need to install on IIS if it's just a client certificate. Is this correct?
We had an issue with our automated build machine yesterday. We are using a TFS Build server, and when it tried to automatically download NuGet packages, we got the infamous "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel" error.
There are a lot of threads around the 'net regarding why this happens. That isn't my question. It can be fixed easily enough by changing your NuGet repository from
https://nuget.org/api/v2/
to
http://nuget.org/api/v2/
or
http://packages.nuget.org/v1/FeedService.svc/
What I'd like to know is why the repository is using SSL in the first place? I assume it is there for a reason, but I can't figure out what. There is no login that would require security. I can't think of any information being sent that would need to be secure. I just want to make sure that by using an unsecured connection (which works just fine) we aren't somehow compromising our build machine.
Can anyone explain what is gained from connecting to NuGet using a secured connection?
I can't think of any information being sent that would need to be
secure.
It is not necessarily because the information you exchange with nuget.org contains anything secret and thus needs to be secure. By using using SSL you will be certain that it actually is nuget.org you're talking with. Without SSL, somebody might in theory be feeding you bogus packages, and that might be a security problem.
As for the issue you're experiencing with "Could not establish trust relationship for the SSL/TLS secure channel", we've had a similar problem when we started using a new build server:
If you look at the SSL certificate presented by https://nuget.org/, the certification path is: GeoTrust Global CA > RapidSSL CA > *.nuget.org
GeoTrust Global CA was missing as a trusted CA on our new build server, so the problem was easily solved by adding them to the build servers list of trusted root CAs (using the MMC console with the Certificates snap-in).
Update:
On a later service, I've experienced the same SSL issue, and adding GeoTrust as a trusted CA alone didn't solve the problem. In addition, the server was also missing to root CA for https://go.microsoft.com/, which is Baltimore CyberTrust Root (go to https://microsoft.com, and you'll be able to view and download the certificate). Adding this to the servers list of trusted root CAs solved the issue.
I'm about at the end of my rope with Windows Azure Tools and SSL configuration in the ServiceDefinition/ServiceConfiguration files in a cloud project.
At first, I had a web role with RDP enabled (and certificate configured, etc). All that worked for a long time. Then I added an SSL certificate for an https endpoint. It wouldn't deploy because of certificates not being installed in my localmachine/personal store, etc. After messing with it, somehow I've gotten into a bad state where even if I completely remove all configurations having to do with RDP or SSL, I still get this from the emulator:
Windows Azure Tools: Warning: The SSL certificate 'Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption' for endpoint 'HttpsIn' of role 'My.Web' was not found in the local machine's certificate store.
Windows Azure Tools: Warning: Certificate identification setting 'Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption' for role 'My.Worker' specified in the service configuration file is not declared in the service definition file in the Certificate or as part of an SSL endpont
Like I said, there is no such configuration in any of my files, and when there were, they hadn't changed from the time that they worked until this. I tried deleting the dftemp directory where the deployments get placed, I've cleaned and rebuilt the cloud project, I've killed visual studio and the emulator(s), and still always wind up back in the same place.
Has anyone else seen this?
I'm not sure what happened, but after leaving for the day and coming back this morning, I found that a system reboot seemed to clear the issue. I have no idea why, but this seems to have resolved itself.
for first error, you have to remove certificate from certificate section of your service configuration file(cscfg). This certificate is used for encrypting your RDP password.
For second error, I think if you remove above section, it will automatically disappear. Also ensure that you have removed modules RemoteAccess, RemoteForwarder from service definition file(csdef)
We have an existing certificate (global sign) that works fine when a Windows Mobile application (.NET 3.5) tried to consume the web service (also written in .NET 3.5) that is hosted on IIS.
However the when we make the re-issued certificate (global sign) live, the Windows Mobile application is failing to connect to the web service, the error we are getting is "Could not establish trust relationship with remote server". Ive tried searching for this on Google many times and have not found a suitable fix.
We have also tried to copy (and install) the ROOT and intermediate certificate in the chain to the device, but this still does not work.
When we test the new certificate with a PC web browser (IE, Firefox, Opera), a Desktop application that consumes the web service (.NET 3.5), and even Internet Explorer on the Windows Mobile device the .NET web service definitions/documentation page is show without problems (no warnings, or errors), it seems to only be an issue on the windows mobile device when using a compact framework (3.5) application is trying to consume the web service.
We have validated that the certificate is installed correctly on the SSL shopper site, and after our google searches we came across and implemented (as a test) a "trust all" ICertificatePolicy handler, this has resolved the problem, however i was hoping that this problem could be addressed by configuration/setup change rather than a code change and a re-deployment of over 150 windows mobile based devices.
The ICertificatePolicy hander did show up the error that was being returned when trying to validate the certificate: the problem parameter was set to: -2146762481 (0x800B010F in HEX), which i believe is the "CN No MATCH" error, however Ive searched for this in both its numeric, hex and name form and have yet to find a resolution other than the "Trust all" code change.
I thought I would post the answer here in case anyone else runs in to this problem. I've not found a 100% rock solid explanation, but we have managed to make it work and this has made me come up with a hypothesis as to the problem:
It appears that the compact framework seems to be taking the first Common Name (CN) off the "Subject Name Alternative" field of the SSL certificate and only evaluating the certificate against that whilst the full framework, IE and IE on the mobile device seemed to be using both. My reasoning for believing this is below:
The PDA application was accessing the url:
https://AMobileWebService.com/Webservice.asmx
Our old SSL certificate that worked had the following in the "Subject Alternative Name":
DNS Name=AMobileWebService.com
DNS Name=www.AMobileWebService.com
And the new certificate that did not work was contained the following in the same field:
DNS Name=www.AMobileWebService.com
DNS Name=AMobileWebService.com
When we changed the application to use https://www.AMobileSebService.com/Webservice.asmx, the old certificate (that was previously working) failed to establish a trusted relationship, and the new certificate worked (but previously did not).
As I mentioned earlier this leads me to believe that the .NET CF is only retrieving the first name in the SSL certificate and then evaluating the url host name against that, rather than doing it against both as in the full .NET Framework.
We came to this conclusion by implementing a "trust all certificates" work around that we found on stackoverflow:
https://stackoverflow.com/questions/6552598/system-net-webexception-thrown-when-consuming-a-web-service-over-https
The problem parameter on the workaround was returning the value -2146762481. Searching on hex representation of the value (0x800B010F) pointed me to the following information: https://blogs.technet.microsoft.com/rrasblog/2007/09/26/how-to-debug-sstp-specific-connection-failures/
The error turned out to be the constant : CERT_E_CN_NO_MATCH
I am at my wits' end on this one.
FYI, I work in infrastructure, not .net development, so I know very little about WCF and next to nothing about Visual Studio as an environment, but I don't think that's where the problem lies.
We have a WCF service running on a couple of IIS 7.5 servers on our internal network. This is exposed to the outside world via reverse proxy on Apache 2.2.15 on Fedora 11. The reverse proxy handles load balancing between the IIS servers, as well as SSL.
The WCF service is configured to use transport level security, and the IIS servers have self-signed SSL certificates. The reverse proxy does not authenticate the IIS servers, and the only reason we have SSL on the IIS servers in the first place is so the WSDL will present the correct location URL.
We thought we had it working perfectly, but there's one annoying and crucial exception: the WSDL can't be added as a service reference in Visual Studio on machines running Windows Vista or later. On an XP machine, it's fine, but anything later throws the following error:
There was an error downloading
'[URL]'. The operation has timed out
Metadata contains a reference that
cannot be resolved: '[URL]'. An error
occurred while making the HTTP request
to [URL]. This could be due to the
fact that the server certificate is
not configured properly with HTTP.SYS
in the HTTPS case. This could also be
caused by a mismatch of the security
binding between the client and the
server. The underlying connection was
closed: An unexpected error occurred
on a send. Received an unexpected EOF
or 0 bytes from the transport stream.
If the service is defined in the
current solution, try building the
solution and adding the service
reference again.
The WSDL is accessible through a browser, or through regular SOAP, on any machine and without any SSL complaints. It's just Visual Studio that has an issue.
Initial Googling revealed that it might be a problem with the cipher suite that VS used, suggesting that VS on Vista or later would by default attempt to use TLS1.0 in HTTPS connections, and if an intermediary device didn't support that protocol, it would just drop the request. This is definitely not the case, though. The reverse proxy explicitly prefers TLS1.0, and even when viewing the WSDL through a browser, it flags up as using TLS1.0 for the connection.
Having pointed the proxy at other functioning WCF services on different IIS servers, the same error occurs, leading me to assume it revolves around the reverse proxy configuration. The trouble is that it seems to be identically configured to another reverse proxy carrying out the same task elsewhere.
It's presumably some transport level issue around how VS establishes HTTPS connections on different operating systems, but I simply don't know enough about it to hazard a guess about what that might be. Anyone have any suggestions?
Well, that was embarrassing.
I'm sure there's some unwritten cosmic law that results in me finding the incredibly simple solution to a problem I've been grinding away at for days about ten minutes after posting it up on StackOverflow.
The ServerName directive in the virtual host config didn't match the URL. It did match the certificate (which has a Subject Alternative Name, so it didn't throw up any SSL warnings), but that wasn't the name I was accessing it with.
I'm assuming there's some extension of TLS1.0 that VS uses which enforces this, which isn't used by browsers or SOAP clients. This is probably useful information for anyone else trying this with a certificate that has Subject Alternative Names. It wouldn't have come up otherwise.