Closed HappyNomad closed 6 years ago
@javiercn
@HappyNomad Are you trying to host asp.net core inside a UWP application or do you have a UWP application that talks to an asp.net core application.
@javiercn I have a UWP application that talks to an asp.net core application.
I am also encountering this issue. any resolution found?
I think this is more of a question about trusting self-signed certificates in UWP. My recommendation would be to ask about it on Windows specific channels or on a site like stackoverflow.
From what I can see taking a quick look at it, there is an HttpBaseProtocolFilter class that can be passed as an instance to the HttpClient instance in order to disable the validations
ilter.IgnorableServerCertificateErrors.Add(
ChainValidationResult.Untrusted |
ChainValidationResult.InvalidName);
If not, try passing a custom certificate validation callback as in regular .NET with https://msdn.microsoft.com/en-us/library/system.net.http.httpclienthandler.servercertificatecustomvalidationcallback(v=vs.110).aspx
Whatever you do, DO NOT USE THIS CODE IN PRODUCTION as it will invalidate any validation on the certificates.
Closing this issue as there's no more action to take here.
@javiercn I got your suggestion working in the following code:
using ( var handler = new HttpClientHandler() ) {
#if DEBUG
handler.ServerCertificateCustomValidationCallback =
( message, cert, chain, errors ) => { return true; };
#endif
using ( var client = new HttpClient( handler ) ) {
But if the goal is to ignore SSL validation, then why not just turn off SSL? That's what I've been doing. I've returned to this issue, though, because I want to get it working as similar as possible to how it needs to work in production. For that, I'm looking into certificate pinning. Does it sound like I'm on the right track?
@HappyNomad Certificate pinning has nothing to do with this. To make it work in the most similar way as how it would work in production, you would need to find a way for the UWP app to trust the local HTTPS development certificate during development.
I don't have any clue on how to do this if UWP doesn't look at the trust root on the certificate store. I would suggest contacting someone on the UWP forums.
Sorry I can't be of much help.
@javiercn Okay, I asked on the UWP forum about making an app use the local certificate store. UPDATE: I came across this question, the first part of which led me to run certlm
, copy the localhost
certificate in Personal
, and paste it into Trusted Root Certification Authorities
. That resolved the exception I originally mentioned; although, this certificate stuff still being new to me, I can't explain for sure why.
Certificate pinning has nothing to do with this.
I'm just today learning about SSL and certificate pinning, and this statement confuses me. Wouldn't certificate pinning bypass the "need to find a way for the UWP app to trust the local HTTPS development certificate during development"? My understanding from what I just read is that certificate pinning means ignoring the local certificate store, and instead only using the pinned certificate. Please tell me if I'm misunderstanding.
@HappyNomad Maybe we are talking different things. I understand HTTP public key pinning for certificate pinning, but I believe it has a different meaning for you/in the UWP platform. I'm no expert on UWP so maybe doing certificate pinning on UWP is a way to solve this in development.
Trusting the developer certificate during development (whatever form that takes) is the correct approach for it. Just remember that if you require custom code in your app to achieve that you don't include it in your production setup.
I would also not rely on '#DEBUG' to pivot the code but introduce a local symbol for the environment '#LOCALHOST' or '#DEVELOPMENT' and turn it on if not explicitly specified on the DEBUG configuration option. That way you can produce DEBUG and RELEASE builds that work with localhost if you need to do testing.
Hope this helps.
@javiercn Thanks for you help.
Regarding certificate pinning, my nascent understanding leads me to believe it's achievable in UWP using this feature. According to this, a UWP app container can have its own certificate store. According to this, the certificate therein can be trusted to the exclusion of the system store.
I got my UWP app to trust the developer certificate by means of certlm
. The solution didn't require extra code. In the local machine's certificate store, I copied the localhost
certificate from Personal
and pasted it into Trusted Root Certification Authorities
. The same certificate was already in the user certificate store's Trusted Root Certification Authorities
, but a UWP app can't access there.
The certificate I needed to copy over, that my Asp.Net Core web API uses, was "IIS Express Development Certificate" rather than "ASP.NET Core HTTPS development certificate". The latter was already in the user's MY store so for others reading this thread, according to this, if that's the one your web API uses then you can specify "the sharedUserCertificates capability in the manifest" to grant "an app container read access to the certificates and keys contained in the user MY store".
@HappyNomad you solution is probably the best among others
.Agreed. Had to copy the certificate from Personal to Trusted Root Certification Authorities using mmc's Copy/Paste. That was lots of hours to find this gem.
I ported my WebAPI from Asp.Net Core 2.0 to release candidate 2.1. The default template enables SSL, but I couldn't get it working. This exception is thrown:
How can I get SSL to work in my projects? I'm new to working with SSL in .NET so hopefully it's easy to answer for someone familiar with it.
I thought the certificate stuff was handled by VS when I ran the project. Since I keep getting the exception, I manually ran the following commands:
The security warning popped up and I clicked 'yes'. Why is the same exception still thereafter thrown? I've tried passing
new HttpClientHandler { ClientCertificateOptions = ClientCertificateOption.Automatic }
toHttpClient
's constructor, but alas it's always the same exception.