Turns out that if the client sends a request signed with his certificate that certificate is ignored by IIS and not passed to managed code. This is because there's <system.webServer><security><access sslFlags> property that is set to "None" by default and that means "ignore the certificate".
Changing that value is not allowed by default because <security> section is locked and so it must first be unlocked. Clearly someone made an effort to disallow certificates passing to managed code by default.
Why is this the default? Why not just let the certificate through and not touch it?
Related
For some strange reason I have to deal with client apps that can be configured to use either JWT or MTLS. If the server finds an Auth header I will use the token in there. On the other hand, if the token is not found but a client cert is given, I can use that instead. However if the Auth header is present I don't want to require the client cert and I will ignore it if passed, even if it is wrong.
I know I can set ssl_verify_client optional; which will mean ngx.var.ssl_client_cert is populated and I can refer to it in Lua script specified in access_by_lua_file. Then I know how to load the cert as an x509: local x509cert = x509.new(ngx.var.ssl_client_raw_cert, "PEM"), that loads fine.
Question is, how do I verify the client cert once I have loaded it? If there is a key in nginx.conf like this: ssl_certificate_key tls.key; then should I verify the client cert against that? If so, how do I read it?
Or is there an easier alternative to implementing optional MTLS verification?
I have an ASP.NET webforms/mvc hybrid app deployed on IIS 10. I have two bindings for this app one with just a localhost:portNo binding and another with DNSDomainName:portNo binding. Both are Http bindings. SSL is turned off. I get the error
"This attempt to set a cookie via a Set-Cookie was blocked because it had the "Secure" attribute but was not received over a secure connection."
when I test the DNSDomainName:portNo binding (it is failing to set sessions). The localhost:portNo binding works without any issues. Why is this happening? and how do I fix this?
Your cookies are configured to require an HTTPS connection. When you try to set them on a non-secure connection, they will be rejected.
Check your web.config file settings for:
<httpCookies requireSSL="true" />
Change that setting to false, and your session cookies should start working.
NB: Once you publish your site, it should only ever be served over HTTPS, and this setting should be changed back to true.
Secure Cookie Attribute | OWASP Foundation
The localhost binding works because most browsers have special-case code to treat connections to that host name as "secure", even if they don't use HTTPS.
Locally-delivered resources such as those with http://127.0.0.1 URLs,
http://localhost and http://*.localhost URLs (e.g.
http://dev.whatever.localhost/), and file:// URLs are also considered
to have been delivered securely.
Secure contexts - Web security | MDN
I have a request to allow customers to select to authenticate to our service using mTLS (Mutual Authentication). The problem I have is I want to allow this only on one endpoint and only in special circumstances. I do not want to globally accept or require Client Certificates on each request. The setting in IIS allows Ignore, Accept, or Require.
When I set it to Accept and browse to the site in Chrome I get this pop-up
Is there a way to accept the certificates if they are passed to a specific endpoint but not change the behavior of other endpoints?
To enable SSL Negotiation settings on a specific route you can apply that setting to a specific location
<location path="Route/Goes/Here">
<system.webServer>
<security>
<access sslFlags="SslNegotiateCert"/>
</security>
</system.webServer>
</location>
Depending on how your IIS is setup this may cause a 500 error saying "This configuration section cannot be used at this path. This happens when the section is locked at a parent level." If that happens you need to enable the SSL Settings Read/Write flag as seen here:
Or using Powershell:
Set-WebConfiguration //System.WebServer/Security/access[#sslFlags] -metadata overrideMode -value Allow -PSPath IIS:/
I am transfering a website and when am navigating to a page my url is changing from HTTP to HTTPS. Here am getting the Privacy Error message in my browser.
How can I avoid this in moovweb transformation?
Let’s take the example of http://mlocal.erin.ne.jp/
When we are choosing Japanese version its pointing to https://mlocal.erin.ne.jp/jp but in my browser when its moving to secure site am getting Private error.
How can we set-up the config to avoid such error?
I tried with ssl_whitelist but no luck :(
{
"host_map": [
"$.erin.ne.jp => www.erin.ne.jp"
],
"ssl_whitelist": [
"erin.ne.jp",
"erin.ne.jp/jp",
"https://erin.ne.jp/jp"
]
}
Thanks in advance !!!
The ssl_whitelist configuration option is only necessary if the website you are trying to transform has invalid certificates. Typically, this might be a staging website where it is known that the certificates are invalid. So this option is unrelated to the problem you are seeing.
During local development, the Moovweb SDK will load a self-signed SSL certificate for the local domain. This is provided as a convenience to simulate SSL traffic.
When you hit https://mlocal.erin.ne.jp, that is your local server with invalid SSL certificates. Because there is no chain back to a root certificate authority, your browser will not trust the certificate.
If you acknowledge the error, you will be able to proceed. I am only recommending this because this is a local development situation only. During normal web browsing, take care when you see similar messages.
This is completely separate from production-ready projects that will be hosted on the Moovweb cloud. In production, you will have to acquire valid SSL certificates that matches the production domain name you select (typically m.erin.ne.jp, t.erin.ne.jp, or www.erin.ne.jp for a single-domain project). Once this is set up properly, you will not see any SSL certificate errors on your production domain.
I have a dev server in our office that is behind the firewall. The hostname is franklin. We name all our servers after scientists or inventors.
When I set an HTTP cookie:
Set-Cookie: user=kenny; expires=1245424860.11; Path=/; domain=franklin
The cookie doesn't set. I have tried the following with no luck.
.franklin
.franklin.local
franklin.local
.franklin.localdomain
franklin.localdomain
Do I have to set the hostname to something different or can I set this cookie through some magic I don't know already?
RFC 2109 says:
To prevent possible security or privacy violations, a user agent
rejects a cookie (shall not store its information) if any of the
following is true:
The value for the Domain attribute contains no embedded dots or
does not start with a dot.
The value for the request-host does not domain-match the Domain
attribute.
And also:
Domain Defaults to the request-host.
If your host is franklin:
Cookies with domain=.franklin will be rejected, because it has no embedded dot.
Cookies with domain=.franklin.local will be rejected, because it does not match the actual host name of your server.
The solution is to rename your hostname to franklin.local or franklin.<tld> and set the domain attribute of the cookie accordingly (domain=.franklin.<tld>). Alternatively (as you found out), do not specify the domain, and let the user agent fallback to the request host.
Are you setting the cookie from the right domain? You should access the website over http://franklin/ otherwise it wouldn't work (see: same origin policy).