Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Guidance on Thinktecture IdentityServer v3 - certificates

Tags:

I am working up a demo of Thinktecture IdentityServer v3. The intention is to have the identity server run as it's own website under Azure Websites.

There will be other (more than one) Azure Websites that will use the identity server to authenticate users.

Based on the getting started walkthrough (see https://github.com/thinktecture/Thinktecture.IdentityServer.v3/wiki/Getting-started) I have this mostly working.

Where I am having trouble is with the certificates.

For the demo, I'd like to create my own certificate - but I am unsure of what I need to do. Any guidance would be helpful.

Other questions I have on this:

  1. Are self-signed certificates able to be used?
  2. In a production scenario, would self-signed certificates be acceptable, or would they really need to be signed by a trusted root authority?
  3. How would these certificates be installed into an Azure Website (or can I load from disk)
like image 783
Brendan Green Avatar asked Oct 30 '14 13:10

Brendan Green


2 Answers

Well - strictly speaking you need two certificate - one for SSL and one for signing - technically they could be the same - but don't have to. They also have different requirements.

For SSL - you need have a cert that is in the trusted list of your clients. Typically this is either a cert from a commercial CA - or from an internal PKI.

For the signing cert - you can generate your own - e.g. using makecert.

IdSrv is pretty flexible in loading certs - you can retrieve them from arbitrary sources - typically from the windows certificate store (when you have admin level access to the server) - or the file system, or from an embedded resource.

Our sample host uses the embedded resource approach which does work fine for Azure WebSites. For production scenarios you typically want more flexibility (e.g. for roll over) - so I would look into loading it from e.g. blob storage.

like image 130
leastprivilege Avatar answered Sep 22 '22 15:09

leastprivilege


Expanding on the leastprivilege answer I think the 'proper' way is to install them in the Azure trust store but in my case I supplied them from embedded resources as in the idsrv3 example.

Here are some specifics that worked for me. Creating a self signed cert:

        "C:\Program Files (x86)\Windows Kits\8.1\bin\x64\makecert.exe" -r -pe -n "CN=MyAppIdentity" -sky signature MyApp.cer -sv MyApp.pvk
        "C:\Program Files (x86)\Windows Kits\8.1\bin\x64\pvk2pfx.exe" -pvk MyApp.pvk -spc MyApp.cer -pfx MyApp.pfx -pi MyPassword -po MyPassword

Despite the pvk2pfx.exe docs, I found that if -po is not supplied then the pfx would not keep the same password as the pvk and X509Certificate2() would fail with a password issue.

The idsrv3 sample cert worked fine on azure for me, using the idsrv3 sample code:

        var assembly = typeof(Certificate).Assembly;
        using (var stream = assembly.GetManifestResourceStream("MyCompany.Identity.Website.Config.idsrv3test.pfx"))
        {
            return new X509Certificate2(ReadStream(stream), "idsrv3test");
        }

However when I made my own cert it worked fine in local testing using the code above, but on Azure I had to add some extra flags to get it to work. I'm not necessarily sure the implications of using these, but they work, so that's a start:

        using (var stream = assembly.GetManifestResourceStream("MyCompany.Identity.Website.Config.MyApp.pfx"))
        {
            return new X509Certificate2(ReadStream(stream), 
                "MyPassword", 
                X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);
        }
like image 42
bitcoder Avatar answered Sep 19 '22 15:09

bitcoder