A fatal error occurred when attempting to access the SSL server credential private key: 0x8009030d
First published on MSDN on Apr 28, 2017 Recently, I have assisted a Premier customer who installed a new certificate on Windows Server 2008 R2 but was unable to bind the certificate to the Website hosted on IIS.
HTTP ERROR 401 - This page isn’t working right now. However, google Chrome works fine.
Hello all, I am currently getting a HTTP Error 401 message in Edge (Beta). It only happens when trying to authorise via ADFS, Azure AD authorisation is working as expected. When I try the same operation in Google Chrome, everything is working as expected (see pic). I have completed the following: Cleared browser history. Cleared password history. Removed any relevant entries from credential manager Renewed my certificate. Only other relevant info I can think of is that I changed my password at some point last week. Many thanks in advance.
API Management – Validate API requests through Client Certificate.
Azure APIM – Validate API requests through Client Certificate using Portal, C# code and Http Clients Client certificates can be used to authenticate API requests made to APIs hosted using Azure APIM service. Detailed instructions for uploading client certificates to the portal can be found documented in the following article - https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-mutual-certificates-for-clients Steps to authenticate the request – Via Azure portal Once we have setup the certificate authentication using the above article, we can test an operation for a sample API (Echo API in this case). Here, we have chosen a GET operation and selected the “Bypass CORS proxy” option. Once you click on the “Send” option, you would be asked to select the certificate that you would have already installed on your machine. Note – This is the same certificate that you would have uploaded for your APIM service and added to the trusted list in the certificate store of your workstation. After successful authentication and request processing, you would receive the 200 OK response code. Upon maneuvering to the trace logs, you can also see the certificate thumbprint that was passed for authentication. The inbound policy definition used for this setup is as below: (Kindly update the certificate thumbprint with your client certificate thumbprint) <choose> <when condition="@(context.Request.Certificate == null || context.Request.Certificate.Thumbprint != "BF3D644C46099A9D7C073EC002312878B8F9B847")"> <return-response> <set-status code="403" reason="Invalid client certificate" /> </return-response> </when> </choose> Through C# or any other language that supports SDKs- We can use the below sample C# code block to authenticate API calls and perform API operations. Kindly update the below highlighted values with your custom values before executing the sample code attached below Client certificate Thumbprint: BF3D644C46099A9D7C073EC002312878B8F9B847 Request URL: https://testapicert.azure-api.net/echo/resource?param1=sample Ocp-Apim-Subscription-Key: 4916bbaf0ab943d9a61e0b6cc21364d2 Sample Code: using System; using System.IO; using System.Net; using System.Security.Cryptography.X509Certificates; namespace CallRestAPIWithCert { class Program { static void Main() { // EDIT THIS TO MATCH YOUR CLIENT CERTIFICATE: the subject key identifier in hexadecimal. string thumbprint = "BF3D644C46099A9D7C073EC002312878B8F9B847"; X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser); store.Open(OpenFlags.ReadOnly); X509Certificate2Collection certificates = store.Certificates.Find(X509FindType.FindByThumbprint, thumbprint, false); X509Certificate2 certificate = certificates[0]; System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; ServicePointManager.ServerCertificateValidationCallback = new System.Net.Security.RemoteCertificateValidationCallback(AcceptAllCertifications); HttpWebRequest req = (HttpWebRequest)WebRequest.Create("https://testapicert.azure-api.net/echo/resource?param1=sample"); req.ClientCertificates.Add(certificate); req.Method = WebRequestMethods.Http.Get; req.Headers.Add("Ocp-Apim-Subscription-Key", "4916bbaf0ab943d9a61e0b6cc21364d2"); req.Headers.Add("Ocp-Apim-Trace", "true"); Console.WriteLine(Program.CallAPIEmployee(req).ToString()); Console.WriteLine(certificates[0].ToString()); Console.Read(); } public static string CallAPIEmployee(HttpWebRequest req) { var httpResponse = (HttpWebResponse)req.GetResponse(); using (var streamReader = new StreamReader(httpResponse.GetResponseStream())) { return streamReader.ReadToEnd(); } } public static bool AcceptAllCertifications(object sender, X509Certificate certification, X509Chain chain, System.Net.Security.SslPolicyErrors sslPolicyErrors) { return true; } } } Through Postman or any other Http Client To use client certificate for authentication, the certificate has to be added under PostMan first. Maneuver to Settings >> Certificates option on PostMan and configure the below values: Host: testapicert.azure-api.net (## Host name of your Request API) PFX file: C:\Users\praskuma\Downloads\abc.pfx (## Upload the same client certificate that was uploaded to APIM instance) Passphrase: (## Password of the client certificate) Once the certificate is uploaded on PostMan, you can go ahead and invoke the API operation. You need to add the Request URL in the address bar and also add the below 2 mandatory headers: Ocp-Apim-Subscription-Key : 4916bbaf0a43d9a61e0bsssccc21364d2 (##Add your subscription key) Ocp-Apim-Trace : true Once updated, you can send the API request and receive a 200 OK response upon successful authentication and request processing. For detailed trace logs, you can check the value for the output header - Ocp-Apim-Trace-Location and retrieve the trace logs from the generated URL.Should I worry about Timer_ConnectionIdle entries in HTTPERR Log?
First published on MSDN on Apr 28, 2017 While helping customers troubleshooting HTTP-related error, a common question that we face: What is Timer_ConnectionIdle (as we see a lot of them in the HTTPERR log)?, and is this something to worry about?Here is an excerpts from the HTTPERR log:2016-07-05 18:45:09 172.using IIS URL Rewrite module for HTTP to HTTPS
I have installed the URL Rewrite module in IIS 10 to redirect HTTP calls to HTTPS, and I have attempted to set up the redirect but have not gotten it working on one server. Here is the issue: Server1 with IP 1.1.1.1 is running IIS with an https enabled website. An outside DNS has assigned https://gohere.com to IP 1.1.1.1. When users attempt to get to http://gohere.com the connection times out and it is not redirected to https://gohere.com Accessing https://gohere.com works without an issue. Here is the rewrite code from the web.config file. <rewrite> <rules> <rule name="HTTP to HTTPS" patternSyntax="Wildcard" stopProcessing="true"> <match url="http://gohere.com*" /> <conditions> <add input="{HTTPS}" pattern="^OFF$" /> </conditions> <action type="Redirect" url="https://gohere.com" appendQueryString="false" /> </rule> </rules> </rewrite> I have also tried using match url=".*" Any ideas on what might be causing the issue? Or something to try to get it working? Thanks! JimHow to prevent Malicious HTTP Redirections on an Exchange server
Hello All! I am attempting to assist a customer who is trying to pass PCI scans. By default, their IP addresses redirects any HTTPS (443) requests to the Exchange server's OWA. This is fine, except the scan states that the server does not pass a couple of vulnerabilities, one of them being "Redirection via Arbitrary Host Header Manipulation". As a solution, they recommended whitelisting domains, only allow permitted domains to be included in the Host header. I (for the life of me) cannot figure out how to get this to work on a server who's default website is the Exchange OWA. Every time I try to implement a rule in IIS (see: https://techcommunity.microsoft.com/t5/iis-support-blog/host-header-vulnerability/ba-p/1031958) that would redirect any requests that don't match the supplied string to the desired domain name, the page won't load and I get "ERR_TOO_MANY_REDIRECTS" presumably because of Exchange's automatic OWA redirection. Is there a way I can prevent malicious HTTP redirections without breaking OWA? To clarify: there are two domain names on our DNS that lead to the IP address of the Exchange server: mail.domain.com and vpn.otherdomain.com, obviously one is meant for mail and the other one is meant for vpn access over port 8443. The main domain (domain.com) leads to a completely different IP address that hosts their public website. I would like to change the IIS settings on the Exchange server so that mail.domain.com is the only domain allowed to be requested through an HTTP request.
