To set up enrollment for Windows devices Microsoft suggests to set up CNAME for enterpriseenrollment.company-domain.com and enterpriseregistration.company-domain.com to specified Microsoft domains: https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-enroll.
If company-domain.com has configured Strict-Transport-Security (HSTS) for all subdomains this will force https, and as a valid certificate for the mentioned CNAME subdomains doesn't exist at the Microsoft sites, certificate validation will fail in browsers.
Is all relevant usage of enterpriseenrollment and enterpriseregistration done with clients that don't care about HSTS (not browser based) or make exceptions for these sites?
Related
This might be a stupid question, and for that I'm sorry, I'm not well-versed in DNS configurations (so perhaps I shouldn't be meddling in this, lol), but anyhow..
I have a web app running in Azure that is currently undergoing a bit of a name change. Therefore, I want to redirect users trying to access my domain to another domain, let's say https://example.com to https://subdomain.anotherexample.com. I own both domains and have certificates for both of them, but I cannot for the life of me understand how (or if its even possible) to redirect users in this way?
I have both URLs configured as A records for the underlying IPv4 adress, and have tried to configure a re-direct in my cPanel to redirect the domain example.com to https://subdomain.anotherexample.com, but if I try to access https://example.com it just complains that the certificate is from another provider (not my Azure certificate, but instead my web hosting certificate used for other sites). Both URLs are set up as custom domains for the same app service in Azure with SNI SSL certificate bindings where example.com is bound to a standard certificate for that specific domain, while subdomain.anotherexample.com is bound to a wildcard certificate for *.anotherexample.com.
I assume there must be something that's not allowed in trying to redirect between two different domains where https is involved because trying to access http://example.com works (i.e. it re-directs to https://subdomain.anotherexample.com). Do I have to write some kind of script server-side that re-directs users manually?
How do the web protection products which intercept SSL traffic using proxy, work with sites implementing SSL pinning?
Examples of web protection products which intercept SSL traffic -
Blue Coat Proxy SG
Sophos Gateway
McAfee Web Gateway
https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning :
Firefox and Chrome disable Pin Validation for Pinned Hosts whose
validated certificate chain terminates at a user-defined trust anchor
(rather than a built-in trust anchor). This means that for users who
imported custom root certificates all pinning violations are ignored.
In other words, for that kind of interception, SSL pinning is disabled, because the user agree to the interception (by installing a software / a certificate)
We are evaluating feasibility of the following solution for Single Sign On.
Scenario.
Website domain. https://www.example.com
[SSL using multi-server wildcard certificate]
Hosted on Server 1.
Other portal. https://portal.example.com
[SSL using the same certificate (multi-server wildcard certificate)]
Hosted on Server 2.
Solution:
The intention is to share a cookie between the www.example.com and the portal.example.com subdomains, however, for this to work the SSL protocol needs to satisfy the following requirements:
Continue to block Man-in-the-middle attacks.
Encrypt/Decrypt in the same manner for both Server 1 and Server 2. So that they can get the same information from the cookie.
Question is: Is there any limitations in terms of private keys or the SSL protocol perse that will make the solution above not feasible?
Thanks,
Yes, your solution will work and will mitigate most MITM attacks provided the CA that your certificates are purchased from are trusted by the client browsers.
If the cookie is set with domain example.com it will be shared between www.example.com and portal.example.com. It is also advisable to set the Secure flag to make sure it cannot be transmitted over plain HTTP. I am assuming both www.example.com and portal.example.com both have a server-side mechanism to validate the cookie value to authorise each request.
RFC 6265 states:
The Domain attribute specifies those hosts to which the cookie will be
sent. For example, if the value of the Domain attribute is
"example.com", the user agent will include the cookie in the Cookie
header when making HTTP requests to example.com, www.example.com, and
www.corp.example.com.
The old RFC 2109 specified that you needed a . before the domain, however 6265 overrides this. This means if you want to share cookies and make it compatible with very old browsers you should set the cookie with domain .example.com rather than example.com. There is nothing to lose by doing the former as newer browsers will simply ignore the dot.
In your solution, both Server 1 and Server 2 will receive and be able to decrypt the cookie. Note there is not requirement for both servers to have the same certificate - they will both decrypt the SSL session independently using their installed private keys (or rather a shared symmetric key that is transmitted using their installed private keys - to be precise).
However, using a wildcard certificate for *.example.com will be cheaper as the same certificate can be installed on both servers.
I have a webserver (IIS) with an SSL cert for *.mydomain.com
This works perfectly for https://anysubdomain.mydomain.com/ but going to https://mydomain.com/ causes a certificate mismatch error in IE (has not been tested in all other browsers).
Is there any way to work around this, or is it simply a problem with the way IE treats the wildcard in the certificate we have to live with?
The only way to remove the error message when accessing the site at https://mydomain.com is to put the base domain (mydomain.com) in as a Subject Alternative Name in the wildcard. Several certificate providers will add this for free (including DigiCert and Comodo) but you will need to reissue your certificate.
I have a website that came with a SSL site for HTTPS but its on a different server. Example being
my website:
http://example.com
my SSL site:
https://myhostingcompany.com/~myuseraccount/
So I can do transactions over HTTPS and we have user accounts and everything but it is located on a different domain. The cookie domain is set for that one.
Is there a way I can check on my actual site to see if a cookie is set for the other one? And possibly grab its data and auth a user?
I think this violates a major principle of security and can't be done for good reasons, but am i wrong? is this possible?
You can setup a service on either site to handle RPC via HTTP POST requests. You can make it require some sort of session that can only be created by your sites. However, whatever can be accessed over that shared session on the HTTPS site will have no guarantee of confidentiality or integrity.