Wow Edward, you have good timing. :) I was *just* about to post a new question on the StackOverflow link you provided, but you ended up answering it perfectly in regards to self-signed certificates.
Thank you for explaining that. That makes a lot more sense to me now. You have mentioned StartSSL twice now and after taking a look into it, it does look promising. I basically need a signed certificate from them, one that would allow me to specify the serial number and/or extensions, and I will be good to go. I am interested in hearing about asymmetric keys, but I do not think that Azure Key Vault supports that. The only mechanisms to my knowledge are certificates and "secret" app keys (like an API key). I am not sure if that is what you mean, but the result of this is that I have to check it into source control (or find another way of storing it), and if that is the case, I would rather go the certificate route if I can help it. Besides, I like a good challenge. :D I will be contacting StartSSL, and see if they can create the certificates for me. If so, then we have a winner. If not, then I will look into plan b. Thanks again for your time and assistance! Michael -----Original Message----- From: Edward Ned Harvey (bouncycastle) [mailto:bouncycas...@nedharvey.com] Sent: Monday, February 22, 2016 2:23 PM To: Michael DeMond <mich...@dragonspark.us>; dev-crypto-csharp@bouncycastle.org Subject: RE: Dynamically Signing X509 Certificates at Runtime > 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.
