I'm new to IdentityServer4 (2.5) and certificate setup so please bear with me. I think that I've chased down everything I could. I am using it with ASP.Net Core 2.2.0 in a proof of concept app. I have OpenIdConnect with an authority app and a client using cookies with X509Certificate2. Works great on my local machine; however, when I deploy to IIS I get this error:
System.InvalidOperationException: IDX20803: Unable to obtain configuration from: 'https://my.com/mpauth/.well-known/openid-configuration'. ---> System.ArgumentException: IDX20108: The address specified 'http://my.com/mpauth/.well-known/openid-configuration/jwks' is not valid as per HTTPS scheme. Please specify an https address for security reasons. If you want to test with http address, set the RequireHttps property on IDocumentRetriever to false.
The problem is here - http://my.com/mpauth/.well-known/openid-configuration/jwks. If I put that in the browser I get an error; however, if I change http to https I get the data. What setting controls this?
TL;DR
In most cases IdentityServer defers the base hostname/URI from the incoming request but there might be deployment scenarios which require enforcing it via the IssuerUri and/or PublicOrigin options as documented here.
More Info
The URL you are getting in your exception is part of the discovery lookup. It is necessary for validating tokens (e.g. in an applications auth middleware).
There should be a first request to .../.well-known/openid-configuration (the main discovery document) that refers to several other URIs and one of them should be the jwks (signing key sets). In most cases the other URIs in openid-configuration will point to the same primary hostname and protocol scheme your identity server is using. In your case it looks like the scheme changes to HTTP which might be unwanted in this day and age.
Is it possible, that the deployed IdentityServer lives behind a load balancer/SSL termination appliance? This could cause behavior.
I am not sure about IIS details but there might also be some kind of default hostname/URI thing at play.
I have been following the steps in Adding SSL to your custom domain but I am not seeing any changes yet. My website is still running with HTTP only.
I have entered all DNS information under Custom domains and I have a valid my-cert-1 under SSL Certificates but my site is not getting loaded if I go to https://www.my-unsecure-website.com
What could I be missing?
I have verified that I own this domain weeks ago, so it cannot be that I just have to wait 24 hours.
The process is really simple. Verify that you own the domain, upload your SSL certificate and assign a certificate to that domain.
Generally people miss the process of assigning certificate. Make sure to follow step 5 (documentation).
We've got a website:
www.feeltracker.com
This is running on Google App Engine
On Google App Engine, we have Naked Domain forwarding setup, so that:
http://feeltracker.com
redirects to
http://www.feeltracker.com
However, when we try to open the following address in Chrome:
https://feeltracker.com (notice the HTTPS)
We get a Google error page with the following message:
Google
404. That’s an error.
The requested URL / was not found on this server. That’s all we know.
Does anyone know how we can ensure https://feeltracker.com redirects to www.feeltracker.com?
Note that in Firefox we get the following additional information when trying to open https://feeltracker.com:
feeltracker.com uses an invalid security certificate.
The certificate is only valid for the following names:
*.google.com , *.android.com , *.appengine.google.com , *.cloud.google.com , *.google-analytics.com , *.google.ca , *.google.cl , *.google.co.in , *.google.co.jp , *.google.co.uk , *.google.com.ar , *.google.com.au , *.google.com.br , *.google.com.co , *.google.com.mx , *.google.com.tr , *.google.com.vn , *.google.de , *.google.es , *.google.fr , *.google.hu , *.google.it , *.google.nl , *.google.pl , *.google.pt , *.googleapis.cn , *.googlecommerce.com , *.gstatic.com , *.urchin.com , *.url.google.com , *.youtube-nocookie.com , *.youtube.com , *.youtubeeducation.com , *.ytimg.com , android.com , g.co , goo.gl , google-analytics.com , google.com , googlecommerce.com , urchin.com , youtu.be , youtube.com , youtubeeducation.com
(Error code: ssl_error_bad_cert_domain)
Note that we are using the SNI SSL certificate capability on Google App Engine with our uploaded certificate.
When we run SSL diagnostics via http://www.digicert.com/help/ we get the following:
Certificate does not match name feeltracker.com
Subject *.google.com
Valid from 02/Jul/2013 to 31/Oct/2013
Issuer Google Internet Authority
Subject Google Internet Authority
Valid from 12/Dec/2012 to 31/Dec/2013
Issuer Equifax
Any ideas why https://feeltracker.com fails to use the correct certificate, whereas www.feeltracker.com and http://www.feeltracker.com work as expected with our SSL certificate?
Update 16 Sept 2015
It appears this may now work as per Forum post and Issue 10802
Previously applicable info below...
Currently it's not supported. The naked domain redirect is a workaround only for http and you'll probably notice that specific IP addresses you need to be put in your DNS for that differ from the approach and IP addresses for ghs.googlehosted.com.
This seems to indicate that it's different parts of Google's infrastructure and they haven't yet managed to make them consistent or work together. I haven't seen any details on when they will resolve this so it might be a long wait. e.g. Related post from 2009
There is an "acknowledged" issue for Naked domain support so when that's fixed then likely this issue also resolved.
As Google is not going to correctly serve your certificate on their naked domain redirector then for now there are these options that I see:
Make/provide your own reverse proxy (Apache httpd, varnish etc) or use a reverse proxy service (eg. CloudFlare) and point your naked domain there. You'd install your SSL on the reverse proxy, clients would connect there for your naked domain (no certificate errors) and you'd proxy all traffic to your real site. It might create a single point of failure and costs depending what you use.
Rent a cheap VPS where you install a web server, your cert and a redirect script to https://www.feeltracker.com. In DNS map your naked domain to that server. It can be a really cheap linux server as requirements just to redirect are very low.
Find a domain redirect service that supports https and allows you to upload your certificate. Sadly I'm not aware of any.
Use VIP (Virtual IP) SSL and configure it in DNS for your naked domain. I haven't tested myself but it seems it should work, although I did find a old comment here that it may not. Has someone tested? NOTE however as far as I could see the DNS entry has a TTL of just 300 (5mins) and Google doesn't advise it, so even if it did work you might need some scripts to update your DNS entries as there's a strong chance it changes from time to time. If it does work then DNS providers like DNSSimple have an API so it would be possible.
Probably the second option is most applicable in your case as you don't seem to mind about the naked domain (which for many is an issue).
I recently found a good example: https://khanacademy.org/ They appear to use an Amazon EC2 host as per the second option above.
https://khanacademy.org/ Resolving khanacademy.org... 107.20.223.238
Connecting to khanacademy.org|107.20.223.238|:443... connected.
WARNING: cannot verify khanacademy.org’s certificate, issued by “/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287”: Unable to locally verify the issuer’s authority. WARNING: certificate common name “*.khanacademy.org” doesn’t match requested host name “khanacademy.org”.
HTTP request sent, awaiting response... 301 Moved
Permanently Location: https://www.khanacademy.org/ [following]
https://www.khanacademy.org/ Resolving www.khanacademy.org...
72.14.249.132 Connecting to www.khanacademy.org|72.14.249.132|:443... connected.
whois 107.20.223.238
OrgName: Amazon.com, Inc.
OrgId: AMAZO-4
Address: Amazon Web Services, Elastic Compute Cloud, EC2
As of 12 April 2014 it looks like Google makes some progress and now allows mapping of non Google Apps domains (seeissue 8517), although SSL appears not to work for that method yet (see issue 10794 for tracking that).
Best free SSL redirect service I found was CloudFlare. To get it working:
Add your domain and switch your name servers to CloudFlare (signup process walks you through it)
Once added goto CloudFlare Settings and down to SSL. Change the setting to 'Full SSL (Strict)' this requires you to have a valid cert on the subdomain your redirecting to (SNI works fine).
Go back to your websites list, select the domain again and on the options goto page rules. Add a 'Forwarding' rule that redirects https://yourdomain.com/* to https://www.yourdomain.com/$1 (replace www with any subdomain), make sure the redirect is set to 301.
Save your settings and sit back and wait for everything to propagate.
Done. Free and secure SSL redirection for your naked domain.
I had to switch my domain management and nameservers from GoDaddy(G-Suite) to Cloudflare to solve this naked domain redirect issue. I followed Parkers instructions and used the free Cloudflare account and it worked after I turned the redirect rule off and then back on. I switch back from Full(strict) to Full because you now need to pay to upload your own SSL certificate. I am ok with the shared universal SSL certificate from Cloudflare for the time being.
GAE doesn't officially support naked domains. What you're seeing is a limitation of GAE, you're not doing anything wrong. https://developers.google.com/appengine/kb/general#naked_domain
Apparently naked domain redirect on HTTPS is not supported. There is no mentioning of this in official docs. If you look at support docs you see in screenshots that naked redirect specifically states http://.
Judging from Google Groups threads, SSL naked domain redirect is not possible: here, here.
We're configuring SSO for our web app for a customer, but unfortunately we don't have access to the domain controller (one more reason why we don't do more experimenting to check our assumptions). So, we asked to run ktpass.exe and prepare .ktpass file to use for our server configuration.
The issue we are facing is "specified version of key is not available".
I looked up the keytab file (knvo = 5), and checked out the traffic with Wireshark on our web server:
As you can see, kvno = 1 in AP-REQ ticket. I suppose that it's the right ticket to check kvno version.
I know there're compatibility issues with Windows 2000 domain (/kvno 1 must be used for Windows 2000 domain compatibility), but we are said to deal with Windows 2008R2 server (and I can see the value msDS-Behavior-Version = 4 for our domain controller, which matches 2008R2!).
Is there anything like W2K domain mode we are facing with?
Would explicit kvno=1 help to resolve the issue? I.e., ktpass.exe [..] /kvno 1
EDIT #1
The problem was about incorrectly specified SPN. It was HTTP/computer_name#DOMAIN.COM instead of using fully-qualified domain name. This would only work if WINS were enabled, but it turned out it wasn't.
After generating keytab with the correct SPN, everything works fine, and kvno sent according to actual account value.
Will kindly accept answer that explains the effect I observed.
I do not know the internals well, but MIT Kerberos clients do forward resolution of the hostname part of a host-based service principal to canonicalize the hostname. In my experience if the name does not resolve it does affect Kerberos auth. When I setup service accounts for SQL Server to do Kerberos I always have to register an SPN with the host name and the fully qualified domain name because different SQL components seem to use different resolution methods.
In a very basic network topology WINS would be able to resolve the name. Even without WINS though, the NetBIOS service would be able to resolve the hostname. WINS and NetBIOS rely heavily on broadcasts, so if your webserver is on a different subnet, NetBIOS name resolution would fail, and WINS too if not configured correctly. Also Windows need to use the TCP/IP NetBIOS Helper service.
The problem was about incorrectly specified SPN. It was HTTP/computer_name#DOMAIN.COM instead of using fully-qualified domain name. This would only work if WINS were enabled, but it turned out it wasn't.
After generating keytab with the correct SPN, everything works fine, and kvno sent according to actual account value.
Will kindly accept answer that explains the effect I observed.
Reading Google's documentation (http://code.google.com/appengine/articles/domains.html), I understand I can allow users to access my application from my own domain.
I've done that for few NGOs in the past and access like http://mail.[domain]/ is redirected to http://mail.google.com/a/[domain]/.
My questions:
Does it mean an access to http://console.[domain]/ will be redirected to http://appengine.google.com/a/[domain]
What about the URIs like: [user-id]#[app-name].appspotmail.com (for e-mails) or [app-name]#appspot.com (for IMs)
You will not be redirected and the user will only see your domain except for SSL connections.
There are however an "enterprise" version that also allows SSL.
Same goes for e-mails
Mail and XMPP will still be sent/received through [app-id].appspotmail.com and [app-id].appspotchat.com, respectively, as far as I know. I believe there is an open issue about this but I wouldn't be surprised if it wasn't a high priority for the App Engine team.