-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let's Encrypt and SCIM #1190
Comments
Lets Encrypt is more of an OS level thing - it requires a background service running to request, issue and reissue certificates, rather than a framework thing. Even with Kestrel we recommend having IIS, or nginx running in front of it, so the certificate acquisition would be an IIS or nginx service rather than something for Kestrel to concern itself with. It cannot be a nuget package - it's way too late to do this things once your code starts, and we don't have a mechanism for your web application to create OS level jobs, that would be an interesting attack target. As for SCIM the ASP.NET identity pieces are aimed at local databases only, it's meant as a simple starter package for membership, not for integration with AD. Implementing SCIM would go beyond it's target usage, for that you'd use AD itself, rather than membership. |
I get what you mean about ASP.net identity being used for local databases. SCIM is just a standard API to surface that database. Not everyone will want to tie directly to AAD. Lots of startups might see value in having a local directory. It might be helpful to provide something standards based that they won't have to reinvent. I agree completely that people should be building with AAD integration, its brilliant stuff, but a lot of people won't and they will default to "send me a CSV file". Again, I get that certs are typically an os level thing in Windows. Other frameworks are looking to do this, maybe it would be a good idea if ASP.net implemented one of the acme clients in the build or publishing process or something. Their protocol is REST based, maybe there is some tooling that you guys could do to at least start the process without completing it and installing the certificate. I don't know... just spit-balling, but SSL everywhere is good for the entire internet. |
The "problem" with SSL is it's a hosting concern. In order to configure it with an app the app would need to run with enough privileges to change IIS configuration (or ngenx configuration on Linux). That's a really bad idea from a security standpoint, which is why Lets Encrypt's supported software isn't within frameworks, but as background processes that do have that permission. It's not suitable for putting in a framework, as you want your apps to run with least privilege. Really it's work for the IIS team, not us. |
Hi @blowdart, wouldn't this be possible now that ASP.NET Core apps are completely self-hosted? I guess, some library could acquire the certificate on start-up (store it in e.g. Azure Key Vault) and pass it to Kestrel through |
As our recommendation for Kestrel is to host it behind IIS or nginx it's not something we'd be looking at. Kestrel's SSL support is for proxy -> Kestrel, and as we don't have any watchdog timers to even detect cert expiration it's a non-starter right now. |
I'm not saying that you have to do this. :) This sounds like a nice community project. I was just wondering if there still are any technical blockers. why would a timer be an issue? Having a reverse-proxy in front of Kestrel is just your V1 recommendation for security reasons, right? I'm pretty sure lots of people will/want do start exposing Kestrel directly, especially in cases like Azure Service Fabric. Having to setup an additional hardware layer (nginx or Azure Application Gateway) introduces additional complexity and additional costs (but this should be discussed in a different issue, of course) |
If we can harden Kestrel suitable for 1.1 then the recommendations will be revisited. A timer would be the best way, but you could shove that inside the app itself. You'd have to start/stop the hosting pieces to replace the cert. |
https://caddyserver.com/ <- in case you don't know about it. this is a go based server that has integrated support for Let's Encrypt. That's what I want as well 🙈 😄 ! |
A little late to this discussion, but you can do DNS authorization with Let's Encrypt as well. |
Kestrel is now 2.0 and is supported by Microsoft for use on the internet (although it is not recommended due to it being new). There are even implementations of Lets Encrypt for .NET Core in the wild here and here. Also, in 2.0 a lot of startup code has moved to the WebHost
.CreateDefaultBuilder()
.UseLetsEncrypt(options => { ... })
.Build(); A perfect use case for Lets Encrypt would be running in a Docker container behind a level 4 load balancer once ASP.NET Core 2.1 comes out with support for SNI. The performance in this scenario would be blazing fast. |
+1 all the way. |
@blowdart (because you're the ASP.NET Core security guy), @natemcmaster (because you've written https://github.com/natemcmaster/LetsEncrypt), is there any update on this topic? (short-term OR long-term) I really don't understand why this still isn't a priority for the ASP.NET Core / Azure / Microsoft folks. Getting Let's Encrypt integration on Azure is one of the most wanted features on UserVoice! And having a built-in easy solution for ASP.NET Core would at least get us a little bit closer to that. By adding free certs to all HTTP based (Azure) services, you (Microsoft) would have the opportunity to really improve the security of the web and you'd take away a HUGE pain point from thousands of developers who have to deal with weird workarounds, paid certs etc. The web is moving towards HTTPS everywhere and ASP.NET Core / Azure should be at the front of this movement! PS: The community-based solution for Azure App Service is still way too complex and it also doesn't cover any other hosting scenarios (Service Fabric, Kubernetes, Application Gateway, ...). Edit: It's also the most wanted feature here in aspnet/home. |
ASP.NET does not control Azure, nor would adding asp.net support actually work in Azure Web sites, because the HTTPS handshake happens before your site gets the request, so nothing we do would serve to speed Azure support onwards. Given the SNI certificate selection ability it would now be possible for you to select certificates on an individual request basis, which could support the rolling of the certs for sites where kestrel is the only host and has nothing in front of it, so it's possible for someone to implement this. |
SNI* |
That's what https://github.com/natemcmaster/LetsEncrypt does, but I ran out of bandwidth to work on this as a personal project. The code is proto-type quality, but needs polish before I would advise anyone to use it.. I'm happy to add contributors if someone else wants to pick the baton. |
Thanks for your quick responses!
What about directly exposed ASP.NET Core apps on Kubernetes, Service Fabric, ...? Those are very popular and important scenarios that would justify putting some ASP.NET Core team manpower into this IMO. My main frustration is that the looks of this are really bad. Microsoft has closed one of the most-voted requests for Azure Web Apps and told people to use a web job which requires a lot of steps. They've also referred to Azure Key Vault where the Let's Encrypt issue now has more than 3200 votes and it's not even "Under review". Azure Application Gateway only has it on its "long term roadmap" which doesn't mean much IMO. And you're not really taking much interest into this either even though other web servers like Apache and Caddy have support for this. |
Yep, there's only so much we can do in our personal time. Thank you for creating that prototype! You'd have my vote to work on this full-time 😄 |
To be fussy here Apache have support because LetsEncrypt wrote it, Apache did not. Like everything it gets triaged and balanced against other features for each version. This will happen again for this issue in 3.0. I'm not about to make any promises until that happens. |
I'll count on you! 😉 |
@Eilon @muratg @mkArtakMSFT for consideration again. |
@blowdart can you distill this into a specific feature request? It's not clear to me what the feature would be. |
@Eilon "Add support for LetsEncrypt certificate acquisition and rotation in Kestrel" |
Got it. I logged https://github.com/aspnet/KestrelHttpServer/issues/2971 to track the feature request, so I'm closing this issue here. |
Thank you!! |
* Fix empty nonvoid elements in markup blocks. Fixes #1186 * Also update another test
Would asp.net benefit from having https://letsencrypt.org/ support for automatically getting and renewing SSL certificates for a user site? They've defined a lightweight protocol called ACME for requesting, verifying, and installing an SSL certificate. This would be great. SSL all the things.
Also, Azure AD has announced support for SCIM 2.0 (http://www.simplecloud.info/) for provisioning user accounts into an application or service. Instead of integrating directly with Azure AD via the grpah api, lot's of services need their own user directory. SCIM provides a standard API for getting users and groups in and out of a service. When doing the "individual accounts" option in Asp.net tooling it would be great if these end points were exposed for the default user schema.
I posted this on forums.asp.net and they pointed me over here. They mentioned that these features should probably be a nuget package, like everything else these days, but there is a boost to adoption that comes from being "in the defaults" that "SSL Everywhere" could definitely use. It also seems like it's in everyone's interest that standardized user provisioning get some support. Like I said, the AAD team released support for it for that reason. The more people using the cloud the better, right?
The text was updated successfully, but these errors were encountered: