So, I have the following system: there is a client app, which requests the service as follows:
blar.ServiceSecurity wsSecurity = new blar.ServiceSecurity();
wsSecurity.Url = this.tURL + "Security.asmx";
CookieContainer cc = new CookieContainer();
wsSecurity.CookieContainer = cc;
wsSecurity.ClientCertificates.Add(X509Certificate.CreateFromCertFile(certPath));
blar.LoginResult lr = wsSecurity.Login(login, password);
then, a web-service at this.tURL + "Security.asmx"'s Login method has to get that ClientCertificate (certPath) from:
Context.Request.ClientCertificate.Certificate;
and do something with it.
There are two problems:
if IIS's configuration says Require client certificates, i get 403.7 error on calling the Login function;
if IIS's configuration says Accept client certificates, i get CryptographicException "m_safeCertContext is an invalid handle";
but, those problems happen only if client works from Windows 7 x64, when launched on Windows XP, or Windows Server 2003 even, it does just fine.
ca is installed on both machines, configuration seems completely identical in all test cases,
so my question is 'What the hell?'
I don't see anything immediately wrong with your code or configuration, so you might find these tools helpful in figuring out the problem yourself:
SSL Diagnostics for IIS (or for IIS 7, see this)
.NET Network Tracing
Fiddler HTTP(S) proxy debugger (how to decrypt SSL)
SSL tracing
Related
Running an ASP.Net Core application based on IdentityServer 4 on an AWS cluster,
after 14-21 days all outgoing HTTPS requests take 5min or more to finish.
After an investigation found that the WinHTTP Web Proxy Auto-Discovery Service dies with the following error: The endpoint mapper database entry could not be created. not sure if this is the issue or a side effect of something else that breaks lower in the OS.
Environment:
ELB with with an autoscaling group with two instances behind it, issue occurs on both
Windows Server 2019
Notes:
It is a custom AMI but the only difference with the instances that do not experience this is the product is running on it.
Happens on both .Net core 2.2 and 3.1 based versions of the application
Happens on both versions based on IdentityServer4 v2 and v3
The app is deployed self contained
The app uses Kestrel without a reverse proxy in front of it
Tried:
Enabled schannel: no errors in the schannel logs set on trace
No other notable errors in any of the EventViewer logs
Restarting the instance fixes the problem
When running curl.exe -v to an HTTPS site on the machine the request gets stuck on schannel: checking server certificate revocation
The clocks on the instances are OK
Restarting the app process does not resolve the issue
Disabling the HTTPClient in the code using the WinHTTP Web Proxy Auto-Discovery Service service still breaks the service.
For those running into this.
The root of this issue is the WinHTTP autoproxy (wpad) service which is used to autoconfigure proxy settings, WinHTTP 5.1 implements the Web Proxy Auto-Discovery (WPAD) protocol also known as autoproxy, and it must support DHCP. Now this is where the problem occurs, the AWS DHCP does not support DHCP option 252 (used by WPAD) which in turn causes the issue.
The resolution is to disable the WinHTTP service as it is turned on by default in Windows.
I am seeing this exact same problem on a bare-bones AWS Lightsail instance of Server 2019. I am simply using IIS as a reverse proxy with the URL Rewrite module.
Here are some details about my environment/scenario in case it helps narrow down some common factors.
I have zero .Net applications running on this box, it is simply a reverse proxy.
I have 2 web applications, and 2 websites setup in IIS, each is a reverse proxy for a different back-end API.
The websites in IIS on the reverse proxy use the same CA issued wildcard certificate as the back-end API's.
The back-end API's are also hosted in IIS (Server 2012 R2).
The back-end API's run in a PCI compliant environment so IIS Crypto has been used to tighten up encryption protocols/algo's. I have not used IIS Crypto on the reverse proxy yet, so as I type this I'm starting to wonder if there's an SSL aspect to this.
We are working on SP2016 on premise provider hosted add-in. Remote Events for the same was working fine in SP2013 with no issues. Once, upgraded to 2016 when installing the app. We get the following error.
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."
We are using self signed certificates (Root and child certificates). We are following the same process what used to work for SP 2013.
Anyone with similar issues?
Any help would be greatful
I am also experiencing issues with https and SharePoint 2016, something has changed with authentication between 2013 and 2016.
I managed to debug one of our apps in http, and found where it was calling to authenticate the user, for internal use i have http site for authentication. External i am using a proxy.
I have two EC2 servers. One runs Windows Server 2012 R2 and the other runs on Amazon's Linux build. The Linux box is used as a web server with PHP doing the scripting. I would like the Linux server to send a string to the Windows server every time a PHP file (acting as a RESTful end-point) is processed.
I've never done anything similar and was wondering where to start. From the research I've done so far, it seems like using Netcat to create a Telnet connection might do the job. If so, what would the boilerplate code look like? Netcat is a pretty old platform and there's not much to be found in terms of examples from a Google search.
I am also open to other solutions that could solve this problem.
The workflow of what I am trying to do looks like:
A user hits PHP file end-point -> PHP or the server it runs on sends a string to the Windows Server -> Windows server receives the string and starts a script
You could think of exposing this as an endpoint on your Windows server using either of:
IIS + PHP
IIS + CGi/Perl
IIS + Asp
or anything else.
Expose a simple page on IIS (Windows web server) and hit that from within your webservice login (Linux server) whenever the Linux server receives a request. The script/page that is exposed by your Windows server could execute the desired script then.
The page/endpoint that is exposed on the Windows server should be protected so that not anyone could execute it (disabling public ips. Restricting only the Linux server Ip in your firewall rules etc.)
Sample
Within your php webservice - $my_var = file_get_contents('http://WinServerPrivateIp/runScript.pl'); // Make it asynchronous if needed
runScript.pl in Windows - Would execute your actual script.
You could look at calling winexe from within PHP. I haven't done it myself but I've read that this should do the trick.
winexe Sourceforge
Some sample code from within PHP here
I hope that this is of some help to you
Regards
Liam
I’m facing the following issue on multiple (not to say: all) Windows 8.x machines:
Running this piece of code:
var message = new MailMessage();
message.From = new MailAddress("sender#foo.bar.com");
message.To.Add(new MailAddress("recipient1#foo.bar.com"));
message.Subject = "This is my subject";
message.Body = "This is the content";
var client = new SmtpClient();
client.Send(message);
The config:
<system.net>
<mailSettings>
<smtp from="test#foo.com">
<network host="smtpserver1" port="25" userName="username" password="secret" defaultCredentials="false" />
</smtp>
</mailSettings>
</system.net>
against a hosted Exchange Server results in several issues like 5.7.1 SMTP errors (not authenticated, base64 required etc.)
Running the same code on a Windows Server 2008 R2, Windows Server 2012 or Windows 7 works as expected…
Turning of the firewall did not help.
Am I missing same magic on Windows 8.1 machines?
It doesn't matter whether the code runs in an IIS or Console Application.
Setting defaultCredentials to true or false also doesn't matter.
Sending the mail using Windows telnet client works without any problems also.
Update:
Here comes the WireShark SMTP Log:
C: EHLO <LOCALMACHINENAME>
S: 250 mail.myhostedexchange.org Hello [<IP>] | 250 SIZE 104857600 | 250 PIPELINING | 250 DSN | 250 ENHANCEDSTATUSCODES | 250 STARTTLS | 250 AUTH GSSAPI NTLM LOGIN | 250 8BITMIME | 250 BINARYMIME | 250 CHUNKING
C: AUTH gssapi <base64 encoded string>
S: 334 <base64 encoded string>
C: base64 username
S: 334 <base64 encoded string>
C: base64 password
S: 535 5.7.3 Authentication unsuccessful
Update 2:
I compared the Wireshark output from a Windows 8.1 machine and a Windows 7 machine (where everything works fine):
The Windows 7 machine sends something like this:
C: AUTH gssapi <base64encoded>NTLMSSP + some encoded chars.
The Windows 8 machine sends something like this:
C: AUTH gssapi <somehowencodedchars>Token Signing Public Key<somehowencodedchars>WELLKNOWN:PKU2U<somehowencodedchars>SMTPSVCmail.myhostedexchange.org
Update 3:
I tried using SendGrid and it works fine on Windows 8.x machines.
The difference between SendGrid and my Hosted Exchange is that SendGrid only supports
250-AUTH=PLAIN LOGIN
This is similar to my Telnet Login experience.
Update 4:
EnableSSL=true does not fix it.
This could be related to this bug: https://connect.microsoft.com/VisualStudio/feedback/details/785710/mailmessage-subject-incorrectly-encoded-in-utf-8-base64 but this is just with the subject header and not authentication. Keep reading!
Before I changed my answer I was pointing to the Exchange server as the problem. Encoding CSR. (but then changed my approach to the client to see what could be done there since it seemed like Weekend changes server-side would have a lower probability. But then again it just might be the right way to go after all.
I have fetched that information and brought it back:
Create a new CSR on the Exchange server and reissue the certificate
And review this post where a base64 was request to exchange but failed. So the Exchange Server had to have something modified.
http://www.billmorefield.com/index.php/2013/11/29/encoding-csr-on-exchange-2010/
I am seeing a lot of the 64 base interpretation on various different things pointing to a backwards compatibility issue on your exchange server. Windows 8 is throwing something at it and Exchange folds because of interpretation problems.
More client related but along the same lines to try to avoid bumping the 64base encrypt/decrypting problem...Here is a work around attempt from the client side which is basically rendering SSL auth useless (leaving this just to illustrate that people are attempting to approach this from the client side). See if you can set SMTPEnableSSL=N or false in your web config settings. Test and see if it works. I am thinking SSL might be the problem.
http://theoldsewingfactory.com/2011/01/06/enable-ssl-in-web-config-for-smtpclient/
Look here as well. I'll pretty up these links later.
http://social.technet.microsoft.com/Forums/en-US/023d7598-9311-4b84-b1df-81ceda011fe4/bug-smtplivecom-stopped-working-after-win-81-tested-ol2013-win8-my-lan-roaming-user?forum=w81previtpro
This is backwards compatibility issue.
This is for the .NET 4 framework. If you are using 3.5 or 3 it won't work in config.
So then you would look for your host settings somewhere and configure it there.
Reason seems to be due to the base 64 encryption not being able decrypt on your SMTP server.
Ok. To bring back my main points. It is unlikely that this is a Application coding problem considering the code works on some Windows 8 machines with SMTP and older versions of client server setups. This is more related a transport/authentication issue.
Console app
using telnet
on windows 8.1
connecting to a hosted 2010 exchange server.
Approach: Authentication/Security/Relay
Here are some better things to check.
Authentication (this is for sharepoint but it talks about your config file).
Machine Keys
Machine Keys
More Machine keys
Client Certificates
Client Certificates and Windows 8
More on Certificates
Certificate Authority
SSL
Here is discussion on routers, SSL and Windows 8.1
Here is discussion on Multiple Authoritative Domains and Windows 8
I have a web service running under IIS7 on a server with a host header set so that it receives requests made to http://myserver1.mydomain.com.
I've set Windows INtegrated Authentication to Enabled and everything else (basic, anonymous, etc) to Disabled.
I'm testing the web service using a powershell script, and it works fine when I run it from my workstation against http://myserver1.mydomain.com
However, when I run the same exact script on the IIS server itself, I get a 401-Unauthorized message.
In addition, I've tried installing the web service on a second server, myserver2.mydomain.com. Again I can call my test script fine from BOTH my workstation and from myserver1.
So it seems the only issue is when the client is on the same box as the web server itself - somehow the windows credentials are not being passed or recognized.
I tried playing with IE settings on myserver1 (checked and unchecked 'Enable Windows Integrated Authentication', and added the URL to Local Sites). That did not seem to have an effect.
When I look at the IIS logs, I see the 401 unauthorized line but very little other information.
I see basically the same behavior when testing with IE (v9) - works from my workstation but not when IE is running on the IIS server.
I found the answer after several hours:
By default, there is something called a LoopbackCheck which will reject windows authentication if the host header used for the site does not match the local host's name. This behavior will only be seen when the client is on the local host. The check is there to defeat possible reflection attacks.
More details here:
http://support.microsoft.com/kb/896861
The kb item discusses ways to disable the Loopback check, but I ended up just switching from using host headers to ports to distinguish the different sites on the IIS server.
Thanks to those who gave assistance.
Try checking the actual credential that is being passed when you are running on the server itself. Often times you will be running on some system account that doesn't have access to the resource in question.
For example, on your box your credentials are running as...
MYDOMAIN\MYNAME
and the server will be something like...
SYSTEM\SYSTEM_ACCOUNT
and so this will fail because 'SYSTEM\SYSTEM_ACCOUNT' doesn't have credentials.
If this is the case, you can fix the problem in one of two ways.
Give 'SYSTEM\SYSTEM_ACCOUNT' access to the resource in question. Most people would avoid this strategy due to security concerns (which is why the account has no access in the first place).
Impersonate, or change the credentials of the client manually to something that does have access to the resource, 'MYDOMAIN\MYNAME' for example. This is what most people would probably go with, including myself.