I'm trying to authenticate a user using SmartCard Certificates in IdentityServer4.
When I follow the samples provided, Firstly, I'm unable to get my test certificates in the certificate popup in IE or Chrome. There is one Apple Device certificate that pops up for my iPhone and one other one, that could probably be wrong configuration of my test certificates.
But when I select any certificate, it take me to the login screen in ID4.
My question is, what interfaces do I have to implement so that a user can authenticate using a CAC, PIV, SmartCard or X.509 certificate and get back a token if the cert is valid ?
I've already researched the setup needed for Client Certificate authentication
var host = new WebHostBuilder()
.UseKestrel(cfg =>
{
var httpsoptions = new HttpsConnectionFilterOptions
{
ServerCertificate = cert,
ClientCertificateMode = ClientCertificateMode.AllowCertificate,
CheckCertificateRevocation = false,
SslProtocols = System.Security.Authentication.SslProtocols.Default,
ClientCertificateValidation = ClientCertificateValidation
};
cfg.UseHttps(httpsoptions);
})
Can anyone please help if you've implemented similar requirements using IdentityServer4 ?
Related
I'm reading this article on iOS push certificates, and I'm confused about this paragraph:
Your backend sends notifications through Apple's servers to your application. To ensure that unwanted parties are not sending notifications to your application, Apple needs to know that only your servers can connect with theirs. Apple therefore requires you to create an SSL certificate to be able to send push notifications.
My understanding of SSL certificates is that if a server has one, that server is able to encrypt data that it sends to a device. But it says here Apple needs to know that only your servers can connect with theirs. I don't understand how having an SSL certificate ensures that. Does anyone have any insight?
The article shouldn't have used the term SSL Certificate. SSL is the Secure Sockets Layer (which was superseded by TLS many years ago). SSL and TLS define the handshake that is used to negotiate encryption on a connection.
Enabling SSL on a web server required you to have a certificate to verify your server's identity and so this became known colloquially as an "SSL certificate".
While it isn't often used on the web, in SSL/TLS both parties can present a certificate so that there is mutual authentication.
What you typically have is actually an x.509 certificate. This is the case with the push notification service.
An x.509 certificate contains some information including the identity of the certificate holder, their private key and a signature from a trusted party that can be used to verify the information.
For push notifications, the developer generates a certificate request and submits this to Apple who sign it with their private key. Apple is the trusted party in this case.
When this certificate is subsequently presented to Apple's server they can verify that signature using their public key to confirm the identity of the connecting party.
You have has encrypted the message with their private key (Apple can decrypt it with the public key included in the certificate).
What this means is, that as long as the developer has kept their private key secure (which is why you wouldn't connect directly to the push service from your app, for example) then Apple can be sure of the identity of the server making the connection.
If someone was trying to impersonate your server then, as long as you have kept your private key secure, they can't encrypt the data properly. If they use a forged certificate that uses a public/private key pair known to them then the signature on the certificate won't be valid and Apple will reject it.
My goal is to setup Token Authentication Mode in Azure NotificationHub without using certificate on iOS. I generated the token as it is described here. Then I put the Token, Key ID, Bundle ID and Team ID into NotificationHub Apple(APNS) section (I am pretty sure that this is working, because I tried to change token to different value and there was an error: "Error updating notification hub". This means that all values were saved properly.
In my mobile app I followed this tutorial here. If I try to register user to NotificationHub I have this error:
Foundation.NSErrorException: Error Domain=NSURLErrorDomain Code=-1012 "(null)"
UserInfo={NSErrorFailingURLStringKey=https://dev...NotificationHub/Registrations/?
$filter=deviceToken+eq+''&api-version=2013-04, NSUnderlyingError=0x2811b89c0
{Error Domain=kCFErrorDomainCFNetwork Code=-1012 "(null)"
UserInfo={_kCFURLErrorAuthFailedResponseKey=<NSHTTPURLResponse: 0x281903cc0>
{ URL: https://dev...hubnamespace.servicebus.windows.net/dev...NotificationHub/Registrations/?
$filter=deviceToken+eq+''&api-version=2013-04 } { Status Code: 401, Headers {
"Content-Length" = (
0
);
Date = (
"Wed, 25 Mar 2020 11:51:09 GMT"
);
Server = (
"Microsoft-HTTPAPI/2.0"
);
"Strict-Transport-Security" = (
"max-age=2592000"
);
This means that there is an issue with authentication. Before this I had different testing solution with another NotificationHub. What I did differently that I created certificate in apple.developer.com and used Certificate Authentication Method and then I switched to Token Authentication Method. In this sample testing project everything worked without any issue. In my current project I didn't create certificate for APNS.
My question is if I need to create certificate even if I want to use Token? If so what is the point of creating token if I have to create certificate too?
Sorry for the issues you are encountering.
You are correct - if the Portal let you save the credentials then you have it set up correctly. Notification Hub actually authenticates with APNS on save to verify.
Receiving an authentication error when registering a device indicates there was an authentication issue between your iOS application and Notification Hub itself. There would not have been a corresponding call from the Notification Hubs SDK to APNS itself to get that rejection. I would recommend double checking how you are authenticating with your hub, as it should require both the Listen Access Policy/Connection string and the hub name in order to authenticate and register successfully.
This graphic from the Notification Hub docs (https://learn.microsoft.com/en-us/azure/notification-hubs/notification-hubs-push-notification-registration-management#registration-management-from-the-device) shows what I mean by this:
First of all, I would like to thank to Kyle Kamperschroer for helping me out.
To answer my question - you don't need to create certificate if you are using Token Based Authentication.
My connection string and azure hub name were correct. My issue was that RegisteredForRemoteNotifications method in AppDelegate wasn't called. Then the token was empty and it caused authentication issue in NotificationHub.
I solved this in developer.apple.com. I edited provisioning profile and select proper certificates.
There is also one thing which might probably fixed it. In Identifier section I checked PushNotifications and went through configuration without choosing certificate.
If you are using Azure Web Apps to host your web application (let it be an ASP.NET MVC web app) you do not have the possibility to set up the IIS behind the Azure Web App to accept client certificates through an HTTPS connection. My application has some Web API endpoints that would be only accessible if the user has the correct certificate with the allowed thumbprint. However, I have other endpoints as well (and of course the website) that would be accessible without a client certificate. So in my case the only way is to accept client certificates.
I am not sure about that, but if I know well I can still get the client certificate by using OWIN while the SSL Settings in IIS is set to Ignore. If I use OWIN and go through the OWIN environment I can see a key called ssl.LoadClientCertAsync.
I am implementing endpoints that a third-party service will call, so I have no control over the content of the request. I know that there is a ssl.ClientCertificate key, with type X509Certificate, but in my case this key doesn't exist.
I have found some C# solution about using this ssl.LoadClientCertAsync key to get the certificate like in the CheckClientCertificate method of Katana or the solution in this C# Corner article. In every solution that I can find in the net, the author gets this type as a Func<Task> and then calls this task, by for example using the await operator.
var certLoader = context.Get<Func<Task>>("ssl.LoadClientCertAsync");
if (certLoader != null)
{
await certLoader();
...
After that they retrieves the certificate by using the ssl.ClientCertificate key.
var asyncCert = context.Get<X509Certificate>("ssl.ClientCertificate");
In this example, my asyncCert variable is always null. There weren't any ssl.ClientCertificate key in the OWIN context. I have tried to use the X509Certificate2 instead of X509Certificate, but I still got null.
My question is is it possible to get the client certificate in an Azure Web Site while the default SSL setting is Ignore by using OWIN? If yes, why can't I get the certificate using the ssl.LoadClientCertAsync key?
According to your description, I have created my ASP.NET MVC web application for working with client certificate in OWIN to check this issue. The following code could work on my local side:
if (Request.GetOwinContext().Environment.Keys.Contains(_owinClientCertKey))
{
X509Certificate2 clientCert = Request.GetOwinContext().Get<X509Certificate2>(_owinClientCertKey);
return Json(new { Thumbprint = clientCert.Thumbprint, Issuer = clientCert.Issuer }, JsonRequestBehavior.AllowGet);
}
else
return Content("There's no client certificate attached to the request.");
For SSL Settings set to Accept, I could select a certificate or cancel the popup window for selecting a certificate.
AFAIK, we could enable the client certificate authentication by setting clientCertEnabled to true and this setting is equivalent to SSL Settings Require option in IIS.
As How To Configure TLS Mutual Authentication for Web App states about accessing the Client Certificate From Your Web App:
If you are using ASP.NET and configure your app to use client certificate authentication, the certificate will be available through the HttpRequest.ClientCertificate property. For other application stacks, the client cert will be available in your app through a base64 encoded value in the X-ARR-ClientCert request header.
My question is is it possible to get the client certificate in an Azure Web Site while the default SSL setting is Ignore by using OWIN?
AFAIK, the current SSL Settings for client certificates only supports Ignore and Require for now. When hosting your web application on azure web app, for the client users who access your azure web app with client certificate authentication, they could specify the certificate to a base64 encoded value as your custom request header when sending request to your azure web app, then your could try to retrieve the header and verify the cert if the cert custom request header exists. Details, you could follow this sample.
Additionally, you could use Azure VM or Azure Cloud Service instead of azure web app, at this point you could fully control the SSL Settings in IIS.
I want to connect to third party API from my web application. They have given me a certificate file(.p12) and two .pem files.One with certificate information and one with private key.
The issue is when i try to connect to the API, it gives me an error saying 'Signature and/or certificate invalid'. This is how I added the certificate to my http request.
HttpWebRequest request = new HttpWebRequest();
X509Certificate cert = new X509Certificate("<location>","<password>");
request.ClientCertificates.Add(cert);
I want to know what is missing in here. And is there any other way to add certificate to web request.
Thanks in advance
The Application i am working on needs to connect to a webservice over https, The certificate is trusted and valid.
I have used NSURLConnection is previous projects to use soap over http
Can anybody please point the difference between the two above mentioned scenarios,
I also need to understand what exactly happens when connecting over https, is the certificate stored automatically on the device, how does ssl handshake happen.
Any Pointers in this direction will be really helpful.
Regards,
Ishan
I need some clarification. Is the certificate signed by Apple for use with notifications or is it signed by an SSL root certificate authority (like VeriSign)?
Apple signed certificates are only to be used with WebServer to Apple Server communications like the Apple Push Notification Service. They are not intended for iOS device to WebServer.
A SSL certificate signed by a SSL root certificate authority should just work.
I think you are looking for an HTTP over SSL/TLS primer. So, here it goes.
HTTP is an unencrypted channel. The request and response are in a plain text data stream. HTTPS is an encrypted channel. The request and response are in a data stream encrypted using a shared master key. The magic of SSL/TLS is how this encrypted channel is created.
First, the client and server say hello to each other (in a clear channel).
Next, the client downloads the server's public certificate (in a clear channel).
At this point, the client has some work to do. It needs to verify the certificate. It needs to know that it understands the certificate, that the date range is valid, that the certificate is signed by a trusted certificate authority, and that the certificate has not been revoked.
Now, the client knows that it can trust the server.
Next, It sends a few short messages encrypted with the public key of the server (which is in the server's public certificate). These messages can only be decrypted by the server's private key (which only the server knows about). These messages allow the client and the server to negotiate a master key.
Finally, the client and the server begin the normal HTTP request and response using the newly created encrypted channel.
I hope this is what you are looking for. For a more detailed description see: http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
If the certificate was issued by a chain of certificate authorities whose root is trusted by Apple, then there is nothing to do. The iOS device will accept the certificate, as long as it is otherwise valid (ie not expired, not revoked, etc).
If the CA chain's root is not trusted by Apple, you will need to download the root's certificate to the phone. This can be done (I think) via the iPhone Configuration Utility. Enterprise provisioning scenarios undoubtedly support this also.