We are trying to implement the following workflow:
generate private key in browser, using window.crypto
create a PKCS10 certificate signing request in the browser
send the PKCS10 to a server
the server signs the request and returns an x509 certificate in PEM format
the browser stores the certificate for itself
The same thing already works using the keygen tag in the browser and using SPKAC instead of pkcs10. Now, however the browser does not store the certificate returned, just wants to save them. When we try to import the certificate to the browser by hand, we got "the private key for the certificate is missing or invalid".
We suspect that the private key generated by window.crypto.generateKey() does not get stored in the browser's keystore. How to get the private key stored in the keystore?
The implementation of the first two steps is based on http://blog.engelke.com/2014/08/23/public-key-cryptography-in-the-browser/
Update: As some browsers use the OS keystore, I am also looking into the possibility to save the key into the OS keystore through some other way.
What I have figured out so far:
Java cannot be used according to this question: Tell Java to use Windows keystore
In Windows one can use ActiveX controls.
Summary: Found no standard cross-browser and cross-OS way to generate and meaningfully use X509 certificates. There are combinations (new chrome versions (dropping keygen support) on non-windows OS) where there is no way to do this.
Related
We are using IdentityServer4 and our version loads the signing key from a PFX file in file system or from the windows certificate store. Using the certificate works. The question is - which certificate issuer should be used in production?
Is a certificate from a public CA recommended? Or is it enough to have a self-signed certificate (without a CA at all) such as it can be created with IIS Manager?
In our tests we have found that the client could still validate the signature in the access token, even if the signing certificate would not have a valid CA chain on the client.
In the docs, it says that you can also use raw key material instead of a certificate:
http://docs.identityserver.io/en/latest/topics/crypto.html#token-signing-and-validation
In this scenario there would be no CA chain whatsoever.
That leads me to the assumption, that when the client loads the public signing key (via the HTTP(s) endpoint), the CA chain information might not be passed anyways. Is that right? Through the loading mechanism via HTTPs you also have a combined security mechanism.
So my conclusion is that for the signing credential a self-signed cert is just as safe as one from VeriSign. Can this be confirmed?
There is no certificate involved in signing and verifying the tokens. Only a private and public key (RSA or ECDSA key).
However a certificate can be useful to "import/transport" the keys into .NET. So, because of that we don't care about who issued the certificate.
When importing the key, one approach is to bundle the certificate that holds the public key + the private key and store it in a PKCE#12 file (.pfx/.p12 extension). Then load that file into .NET. Before .NET 5 working with keys was a bit hard.
The more important thing is that you can manage and deploy the private key in a secure way and that it is persisted over time.
Optionally, you can add support for key-rotation.
I want to use Google Cloud KMS for asymmetric signing. To complete setup with the destination provider I need to send them a CSR signed with the private key stored in Google. I've found some examples of doing this using Java or Go but I don't need to do it programatically and I don't know those languages anyway. Ideally I'm looking for something command line based using the SDK.
I gave up doing it this way and generated the private key and CSR on a local trusted machine then imported it into Google.
How can I export the Token Signing Certificate that is created when ADFS 3.0 is installed? When I open up the certificate MMC, I am able to see the certificate however the message 'You have a private key that corresponds to this certificate' is missing and I am unable to export the private key. I read in the article ADFS deep dive: Certificate Planning that I can find it in Active Directory in the following container:
CN=ADFS,CN=Microsoft,CN=Program Data,DC=domain,DC=com
However, although I can get to that container, all I see is a GUID inside and do not know how to export the private key out of Active Directory.
How can I get the private key?
******************************************** EDIT ********************************************
In case anyone comes to this later, the certs are actually in the personal cert store of the ADFS service account but they are NOT exportable. You almost certainly want the SSL cert private key NOT the token signing cert private key. The documentation
I was following to set up ADFS for SharePoint was a little confusing. The private key had to exported for the SSL cert, however the thumbprint of the token signing cert had to be placed in the web config. I was incorrectly trying to export the private key of the token signing cert.
******************************************** EDIT ********************************************
You mean the self-signed ones you get with automatic rollover?
If so, where do you see these with mmc?
They are stored in a combination of an AD container and the ADFS DB.
So you can't export in the normal manner.
For a very good reason - security. If you have the private key you can send / hack anything and it will be accepted as coming from ADFS.
The public key is available in the metadata.
If you have to do this, turn off automatic rollover and use your own certificates.
I'm trying to get this external REST webservice that requires both a server-side certificate and a private key (both of which I got from the publisher as *.pem files of that service).
For my testing, I googled and found a way to combine these two pieces into a *.pfx file - and loading a X509Certificate2 instance from that binary file on disk works just fine.
Now I was trying to put this into the Cert Store on my production Windows Server 2008.
I can get the X509Certificate2 from the cert store in my C# code - no problem:
X509Store store = new X509Store(StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadOnly);
X509Certificate2Collection certs = store.Certificates.Find(X509FindType.FindBySerialNumber, "serial-number-here", false);
if (certs.Count > 0)
{
X509Certificate2 cert = certs[0];
// set the certificate on the RestClient to call my REST service
_restClient.ClientCertificates.Add(cert);
}
store.Close();
But when I do this, then the web service barfs at me, claiming it needs a "SSL certificate"...
Also: when I was loading the X509Certificate2 from disk, from that *.pfx file, I had to provide a password - nothing needs to be provided here, when loading from the cert store.... odd....
It seems that even though I imported the *.pfx which contains both the server-side certificate and our private key, somehow I cannot get both back from the cert store...
Any idea how I can get this to work? Do I need to load the private key from the cert store in a second step? How?
These certificates still remain mainly a big voodoo-like mystery to me ..... can anyone enlighten me?
The first thing to check is to see whether the certificate store does have the private key.
Open up the certificate management snappin and find your certificate, double click it and make sure it has the red highlighted section like in the image below:
Next, if the private key is in the store then maybe the account accessing the certificate does not have permissions on the private key. There are two ways to check this:
In the certificate management snappin, right click the certificate > All tasks > Manage private keys. (You should be able to check and edit permissions here)
In your code you could access the PrivateKey property (i.e. Do var privateKey = cert.PrivateKey and see whether you get it back).
You did not write how is the web service implemented.
if it is deployed on IIS
if it is self hosted
Your code to get certificate from store is correct. The question is where did you import the pfx - CurrentUser or LocalMachine store. You are using CurrentUser store in the code example. If you imported the certificate to LocalMachine store it will not be found. Also, please specify the store name - StoreName.My (in MMC or certmgr.msc it means Personal) in the constructor of X509Store (it might be default, but who knows all the defaults anyway :) )
But when I do this, then the web service barfs at me, claiming it
needs a "SSL certificate"...
You need to ensure you have Client Authentication in the extended key usage of the certificate.
Also: when I was loading the X509Certificate2 from disk, from that
*.pfx file, I had to provide a password - nothing needs to be provided here, when loading from the cert store.... odd....
It's how it works. When you have a pfx then the private key in it is secured/encrypted with password (password can be an empty string). When you import pfx to certificate store then the private key is secured/encrypted with other key (not exactly sure what key it is). However you can add another level of protection to the private key by specifying strong protection when importing pfx to the store (I do not recommend it when used with ASP.NET, or web services or anything that does not have a desktop). But when it is your personal certificate to sign emails then it might be good to enable it. Windows will then popup a window whenever an application will try to use the private key.
#DanL might be right about the rights to the private key and his
1) - set rights on private key and
2) - accessing private key in X509Certificate2
are written OK. I would just add to 1) that you are trying to connect to the REST service from a ASP.NET application or another web service on IIS then the name of the account that you need to add permission for is IIS APPPOOL\name_of_the_apppool_your_app_runs_under
I have a custom STS built with WIF. If I have the Relying Party and STS on the same server, I can get it working.
However, I'm getting ID4036 errors when using a remote machine. As I have dug into it, I found that by default in my STS was always encrpyting the outbound token with a local certificate rather than the certificate requested by the Relying Party. One solution would be to install the certiicate used by the Relying Party (public key only) on the STS and code the STS to use that certificate.
However, that creates a problem as I add other Relying Parties on different servers.
Here's an Example:
STS on MySTS - signs tokens with SigningCert.
Relying Party on MyWebServer01 - wants to encrypt/decrypt with MyWebServer01Cert (owns public / private key)
I can install MyWebServer01Cert on MySTS and set the STS to use that for encrypting tokens, and everything should work. However, let's say I want to add a Relying Party application to MyWebServer02. It will not work unless I install the public and private key of MyWebServer01Cert.
I would think that you can simply transmit the public key to the STS and each RP can use it's own - somewhat like SSL. Is this not the case?
Any help / suggestions would be appreciated.
First of all, for encryption only the public key is needed. You actually never want to give away the private key of a certificate.
If you use the WS Federation protocol (usually used for STS scenarios on web sites) the request to the STS is not sent by your RP server, but by the browser of the user. I doub't that you call tell the browser to use the public key of the previous site for communication over https. The encrypted token on the other hand is decrypted by the rp server (meaning that the RP server must know the private key of the certificate used to encrypt the token).
Taking this circumstances into account I am pretty much sure that the public key of the certificate of the RP must be present on the STS and can not be included in the request. Everything else would probably be a dirty hack only working with your custom STS (e.g. including the public key as a paramter).
At least for "passive sign-in" scenarios. For WCF you could attach the certificate of your server as client certificate to your request. But I haven't tried this by myself.