Aspnetcore: Let's Encrypt and SCIM

Created on 21 Dec 2015 · 24Comments · Source: dotnet/aspnetcore

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?

Source

b3nt0

👍31 🎉4

Most helpful comment

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 WebHostBuilder, I imagine adding Lets Encrypt support would be some kind of extension method on it. Something like:

c# 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.

RehanSaeed on 3 Nov 2017

👍9

All 24 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.

blowdart on 21 Dec 2015

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.

b3nt0 on 26 Dec 2015

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.

blowdart on 28 Dec 2015

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 UseHttps(this KestrelServerOptions options, X509Certificate2 serverCertificate), right?

cwe1ss on 8 Jun 2016

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.

blowdart on 8 Jun 2016

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)

cwe1ss on 9 Jun 2016

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.

blowdart on 9 Jun 2016

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 :see_no_evil: :smile: !

cwe1ss on 23 Aug 2016

👍1

A little late to this discussion, but you can do DNS authorization with Let's Encrypt as well.

Xipooo on 22 Feb 2017

Also, in 2.0 a lot of startup code has moved to the WebHostBuilder, I imagine adding Lets Encrypt support would be some kind of extension method on it. Something like:

c# WebHost .CreateDefaultBuilder() .UseLetsEncrypt(options => { ... }) .Build();

RehanSaeed on 3 Nov 2017

👍9

+1 all the way.

kieronlanning on 9 Jul 2018

@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.

cwe1ss on 28 Sep 2018

👍1

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.

blowdart on 28 Sep 2018

SNI*

Tratcher on 28 Sep 2018

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.

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.

natemcmaster on 28 Sep 2018

Thanks for your quick responses!

@blowdart so nothing we do would serve to speed Azure support onwards.

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.

cwe1ss on 28 Sep 2018

@natemcmaster ... but I ran out of bandwidth to work on this as a personal project.

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 😄

cwe1ss on 28 Sep 2018

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.

blowdart on 28 Sep 2018

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! 😉

cwe1ss on 28 Sep 2018

@eilon @muratg @mkArtakMSFT for consideration again.

blowdart on 29 Sep 2018

@blowdart can you distill this into a specific feature request? It's not clear to me what the feature would be.