I have an ASP.NET application hosted on IIS version 10.0 on Windows Server 2019 (Amazon EC2).
In this application i turned on the SSL. So, my client makes a GET request to the server and if the user has any Digital Certificate installed on the machine the browser prompt a certificate select window.
When the user chooses a certificate, the request goes to the backend where we validate the certificate. The problem is in some cases there is no response from the server, it refuses the request, the request appear as (failed) in chrome dev tools and our code dont event get to log the error. In this cases we already analised the clients certificates and there is nothing wrong with them.
What could be happening?
Related
We have an asp.net webforms site we are migrating to IIS 10, server 2022 datacenter Azure Edition VM, from an IIS 8.5 Server 2012 R2 Azure VM.
When testing the site on the new platform, the issue surfaces after a user on AT&T mobile submits credentials at the log in page, is authenticated and redirected to the protected content area. At this point the site hangs, sometimes the protected content page will partially load and/or the connection times out with a reset. Other times it will not load the protected content area at all. Prior to LogIn authentication, that same User can access other non-protected content pages over https as normal.
The site performs as expected when accessing from any other network. Everything also works if a VPN is used to access the site over the same AT&T mobile data connection.
When the protected content area hangs. If we keep the browser open and enable the VPN afterwards using the same Mobile connection the content will load normally without having to reauthenticate.
There are no issues on the original server 2012 R2 running IIS 8.5 even using AT&T mobile.
Other info:
Forms Authentication - Target framework 4.7.2
Confirmed the user authenticates on the server with their login creds and is issued auth cookie over SSL. Auth cookie appears in the response header on client machine. AppAuth Cookie size 3.5kb
Once the page hangs, the user can no longer access any prior page from the unprotected content area until they delete the site cookies.
IIS logs show the Post from the log in and the 302 redirect.
Wire Shark shows a successful handshake on TSL1.2 on the client machine. Sometimes see a RST, ACK in Wireshark after several data packets.
HttpErr Log sometimes indicates Timer_EntityBody.
Confirmed issue exists on multiple devices and connections using AT&T Mobile data. From both a browser and as a mobile hot spot connected to a computer.
No additional Deny filters are configured in the Azure NSG.
Other Actions taken to troubleshoot:
Disabled TLS 1.3 over TCP in IIS Bindings.
Disabled HTTP/2 in IIS Bindings
IIS Rebooted after changes
Re-provisioned a different public IP and NSG for the VM in Azure.
Set Timer_MinBytesPerSecond = 0
What are we missing?
Is there a different setting in IIS 10 vs IIS 8.5 that could cause this issue on certain networks?
I've registered to have my consumer key activated for production and for web hooks notifications.
I have connected my app to my user account and I had received the emails but when checking my server logs after creating a note I do not receive a request to my server.
I have tried requests to the URL from other services and it works fine but Evernote's requests aren't coming through.
I understand there isn't any Evernote support is there anyone that can look in to this?
The main issue was that I was using a "Let's Encrypt" SSL Certificate and Evernote does not support the root CA certificate.
I switched over to a cheaper Comodo SSL Certificate and everything worked fine after a while.
I have an asp.net web app deployed on IIS7. I call the webapp AOps and When I try accessing the web app over https it just crashes saying "Security sertificate required to access this resource is invalid" (first image).
When I try over http the download works fine.
When I access the default IIS app over both http and https it works fine - except that it complains that the address is mismatched.
I have added a .pfx certificate in the certificate store with the same host name as my host, so the certificate should be fine. Any idea where to start reviewing my configuration?
I am used to apache and tomcat but IIS is a different animal. I looked in the IIS log but it's pretty much a black box. Any help would be greatly appreciated.
The certificate error is generated by your browser not the server. There are 3 things the browser cares about.
The name on the certificate needs to match the url you are using. So in your case, the browser wants a certificate issued to "localhost"
The certificate has to be issued by a trusted certificate authority (not self-signed)
The certificate cannot be expired
To solve 1, use a host entry in /etc/hosts. To solve 2, you need to add the certificate to trusted CA store on your local machine. And 3 is pretty obvious.
I'm using BizTalk server 2010.
I'm using the client certificate where I have imported that in IIS as well as Trusted root certificate store. Im using httpsTransport with customBinding. When I try to browse in BizTalk server with https, I'm able to browse, but in the client side, they are not able to browse and they get
403 - Forbidden: Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied."
Is there anything that needs to be set in BizTalk or the settings should be done at the client end?
Is it related to anti virus that is blocking?
It sounds as though you are requiring Client Certificate Authentication when a client attempts to query the web resource, but no certificate is being presented. This is not an anti-virus issue.
You already have the certificate (and Root Authority) on your server which is why you can retrieve the resource successfully from the BizTalk Server.
To resolve this issue on your clients, install the certificate on each client that needs to connect (plus the Root Authority certificate if this is one you have created yourself) - the Client Certificate needs to be placed into the Personal Certificate Store for the user that is attempting to request the resource. Then when you connect from your client, the correct certificate will be presented to the server and Client Certificate Authentication will be performed, resolving your '403 - Access Denied' error.
If you have a large number of clients and you don't want to go through this trouble, simple disable Client Certificate Auth in IIS; your traffic will still be secured through SSL/TLS.
I am installing spnego on a java app server that will authenticate users against Active Directory. I've followed all of the directions closely, and the AD Preauth account has the java app server FQDN in the servicePrincipalName attribute. We already have another java app server with spnego installed that works correctly (I did not do that install and they are no longer here).
I've developed a simple java EE 6 web app to test that spnego is working correctly (jsp page with request.getRemoteUser() ). I correctly get my username response when I run this app on the existing server. When I run it on the new server I'm setting up, I get the following error:
java.lang.UnsupportedOperationException: NTLM specified. Downgraded to Basic Auth (and/or SSL) but downgrade not supported.
Using Fiddler to inspect the sessions, The Authorization: Negotiate token request to the correctly working server is a huge string (the Kerberos token I believe?). The Authorization: Negotiate token request to the non-working server is only 56 characters long (so, NTLM token?). When the server receives that NTLM token, I believe that's when the error is thrown.
I've inspected the responses from the earlier negotiation sessions, but can't find where the server is asking for Kerberos vs. NTLM tokens. How does the browser determine what do send?
Additional details: Java App Server machine: Windows 2008 R2, Java 1.7, Glassfish 3.1.2.2
Client Machine: Windows 7 Enterprise, IE8 on a standard corporate windows domain
Thanks.
The servicePrincipalName isn't just the FQDN; it needs to include the service as well. Like: HTTP/MYSERVER.MYDOMAIN.COM.
The address you're visiting in your web browser must match that FQDN. In fact, you can add any IP in your OS HOSTS file to match this FQDN and it should work OK (even if the IP is 127.0.0.1 and you want to test SPNEGO-Kerberos locally)
From the command-prompt of the browser OS, run: klist get HTTP/MYSERVER.MYDOMAIN.COM, and verify you get a ticket. My guess is that this will fail.
Assuming the third point fails, then you have a larger problem with Kerberos configuration (not your browser/webserver), either on your client OS or your KDC.