@wgross, I know you have experience with client-certificate-authentication because of your work with MIT. My only interaction with it has been using it when working on your systems, which doesn’t even count because to be a developer you don’t need to install any certificates. Can you help me understand them and their difficulty?
- Are client certificates difficult to produce? Does the server certificate producing them need to be signed by a valid certificate authority? Or does the device not-care if you’re installing a certificate that was self-signed?
- Are they difficult to set-up on clients?
- I know that EWL has support for client certificate authentication.
- Was it difficult to implement? (Would it be a disaster to not-use EWL for it?)
- Can forms authentication and client certificate authentication coexist?
Since I’ve only used client certificates produced by MIT, I’m not sure how to set up the infrastructure. But I think you can base the client certs on a self-signed server cert; MIT tells you that you need to trust their CA certificate in your browser before anything else will work.
No. It seems like browsers can generate and store them if the user just clicks a single button on a web page. How that button is implemented, I don’t know.
It’s very easy to read client certs from ASP.NET, if you know the tiny bit of code that you need. Take a look at https://enduracode.kilnhg.com/Code/Ewl/Group/Canonical/Files/Standard%20Library/CertificateAuthenticationModule.cs. The only thing that’s tripped me up has been getting IIS to trust the same CA that issued the client cert–if you don’t do that, the user won’t ever get the prompt to submit their certificate when visiting your app. I think the key is getting the CA into the machine-level certificate store on the server, instead of a user-level store, which is the default behavior.
Forms authentication and client cert authentication can definitely coexist with EWL; I’m doing that right now in EnduraCode Rooms.
1 Like
Thank you Bill- that’s really helpful.