> From: Michael DeMond [mailto:mich...@dragonspark.us] > > learning about the Azure Key Vault, which > suggests using certificates in addition to sending a client id when making > requests. You can see more about this here with a sample article: > https://github.com/Azure/azure-content/blob/master/articles/key- > vault/key-vault-use-from-web-application.md#authenticate-with-a- > certificate-instead-of-a-client-secret
The article you linked is about client authentication based on certs instead of client secrets. They are talking about Azure AD. I'm not familiar with that particular aspect of Azure, but I know how to do it with a Windows server, and I assume Azure just productizes it as a service. In windows server, you would need to install Certificate Server, and create a CA. Then each user account can have identity certs created, and either an admin can download the client identity certs & private keys to distribute to clients, or if the account has an associated password, the individual user can login to a cert distribution center via password to download their identity cert & private keys. Generally the cert distribution service is locked down on a private LAN, but secure services that use cert-based authentication are publicly facing. This is the Microsoft analog to the openssl create-your-own CA and PKI I mentioned before. I'm not sure which is more complex. They're both a bear. > The root of the problem I am trying to solve is that I do not want to check in > sensitive information into (public, ala github) source control, but yet have > an > elegant system that allows me to retrieve necessary data for both local > development and for production environments. When you generate a keypair, it has a public & private component. You can give me your public component, and you can prove you know your private component, but that doesn't mean anything to me about your identity. In order to mean something about your identity, you need to register your public key with a 3rd party that I trust. So when you say "I'm Bob and here's my public key and proof that I have the associated private key," I can see that our trusted CA has signed your public key, indicating "This public key really belongs to Bob" and therefore when you prove you have the associated private key, I'm pretty sure you're really Bob. That's what x509 certificates are for. They're a wrapper around asymmetric keys. Most (or all) OSes have a credential manager, so you can register your private keys and user identity certs (double-click the pfx or pkcs12 file in windows or OSX, for example). I don't know if bouncycastle has a private store of some kind. I know there's something built-in to .NET, but I don't use it, so all I can give you is a starting point: Figure out key containers. Besides storing private keys, I'm pretty sure they either handle x509 certificates too, or there's something very closely related that will handle certs. https://msdn.microsoft.com/en-us/library/tswxhw92(v=vs.110).aspx > The path I *was* taking was to generate self-signed certificates that also > have additional needed information embedded in the certificate's > extensions. Self-signed won't do the job for you, because it's self signed. That's like me giving you my public key, and a certificate that I signed, indicating it's really my public key, but you've never seen me before, so the cert has no more value than just giving you my public key. In order to use a cert for authentication, it'll have to be signed by a trusted 3rd party, and it sounds from your description, it will have to be a CA that you create. I will say one thing, that could potentially simplify things for you: If you're not going to use publicly signed certs (for example startssl identity certs), and you'd like to avoid all the complexity of creating your own CA, it will probably be a lot easier to auth simply using asymmetric keys. The user will need to register their public key with the server in advance somehow. For example in github/gitlab, when you upload your ssh public key, you're registering your public key, and later when you auth using your private key, the system knows that public key belongs to your account. All you need to do is prove you have the associated private key, and you're authenticated.
