install cert in IIS

https://www.digicert.com/csr-creation-microsoft-iis-7.htm
https://www.digicert.com/ssl-certificate-installation-microsoft-iis-7.htm
https://myexchangelync.wordpress.com/2014/12/14/create-a-csr-with-sha256-signature-algorithm/
https://www.godaddy.com/help/generating-iis-7-csrs-certificate-signing-requests-4800
https://community.spiceworks.com/topic/798644-sha2-certificate-requests-iis

Entrust Certificate Services Support Knowledge Base

quoted from http://www.entrust.net/knowledge-base/technote.cfm?tn=7905

Audience: General
Last Modified: 2011-01-18 08:42:02.0

TN 7905 - What are the steps to recover the private key of an SSL certificate in an IIS environment?

Problem:

The SSL certificate is installed but the private key is missing. What are the steps to recover the private key of an SSL certificate in a Microsoft Internet Information Services (IIS) environment?

Cause:

Entrust SSL certificates do not include a private key. The private key resides on the server that generated the Certificate Signing Request (CSR). When installed correctly, the Server Certificate will match up with the private key as displayed below.

     

If the private key is missing,the circled message indicating a good correspondence with private key will be missing as shown here:

 this could mean:

• The certificate is not being installed on the same server that generated the CSR.
• The pending request was deleted from IIS.
• The certificate was installed through the Certificate Import Wizard rather than through IIS.

Solution:
To recover the private key, follow the procedures below.

Part 1 - Snap-In Configuration
Use the following steps to add the Certificates snap-in:

1. Click Start, and then click Run.
2. Type in mmc and click OK.
3. From the File menu, choose Add/Remove Snap-in.
4. In the new window that appears, click Add.
5. Select Certificates and then click Add.
   

6. Choose the Computer account option and click Next.

7. Select Local Computer and then click Finish
8. Click Close, and then click OK. The snap-in for Certificates (Local Computer) appears in the console.

Part 2 - Import the Server CertificateUse the following steps to import your Server Certificate into the Personal certificate store. (If the Server Certificate has already been imported into the Personal store, you may skip this step.)

From the MMC console opened in the above steps:

1. Expand the Certificates (Local Computer) tree in the left preview panel.
   

2. Right-click Personal and select All Tasks > Import.

3. The Certificate Import Wizard appears. Click Next.
4. Browse to the location of your Server Certificate file and click Next.
   

5. Select Place all certificates in the following store and click Next.
   
   

6. Click Finish to complete the Certificate Import Wizard.
   

7. A dialog box appears indicating the import was successful. Click OK.

Part 3 of 3: Recover the Private Key

Use the following steps to recover your private key using the certutil command. 

  1. Locate your Server Certificate file by opening Microsoft Internet Information Services Manager, then on the right side select Tools > Internet Information Services (IIS) Manager. 

2. Once in IIS Manager, select your server, then on the right side, Server Certificates. You will see all certificates currently on that server. Scroll over the certificate you are trying to install, right click, then select View.

  3. There, you can view the certificate information. As you can see, there is no indication of a good correspondence with the private key.

  4. Click the Details tab. Write down the serial number of the certificate.

  5. We will need to recover the private key using a command prompt. In order to recover the key, we must do so using command prompt as an administrator. To do so, slick Start, then on then open all App. Under Windows System, find Command Prompt. Right click Command prompt and then Run as administrator. Confirm the action and continue.

  6. Make sure you are on the right directory in command prompt.
   e.g., if your server directory is “c:/users/srv2012_r2_std_x64”, on the command line type “cd c:/users/srv2012_r2_std_x64”. Note that “cd” is the command used to change directories in command prompt.

  7. Now that we are in the right place, enter the following command at the prompt:  certutil –repairstore my <serial number> where <serial number> is the serial number obtained in Step 2 with spaces removed.

 

  8. If Windows is able to recover the private key, you see the message:
CertUtil:  -repairstore command completed successfully.


If your private key was recovered successfully, your Server Certificate installation is complete.

If the private key was not recovered successfully, you will need to generate a new Certificate Signing Request and submit it to Entrust Datacard to have your certificate re-issued, or re-issue the certificate using your ECS Enterprise account.

Check that your Certificate has been successfully installed by testing it on the Entrust SSL Install Checker.

Part 3 - Recover the Private Key

Use the following steps to recover your private key using the certutil command.

1. Locate your Server Certificate file (for example, server.cer) and double-click it. The Certificate dialog box appears.
2. Click the Details tab. Write down the 8-character serial number of the certificate.
   

3. Click Start > Run.
4. Type cmd and click OK. A Command Prompt window opens.
5. Enter the following command at the prompt: 

certutil –repairstore my <serial number>

Where <serial number> is the 8-character serial number obtained in Step 2 (spaces removed).

6.      If Windows is able to recover the private key, you see the following message:

CertUtil:  -repairstore command completed successfully.

7.     If your private key was recovered successfully, your Server Certificate installation is complete. If the private key was not recovered successfully, you will need to generate a new Certificate Signing Request and submit it to Entrust to have your certificate re-issued.

Affected Products:

• Entrust Certificate Services 1 Year Advantage SSL Certificate Version Not Applicable Language Not Applicable Platform Not Applicable

certutil –repairstore my <serial number> the serial number varies. You should import the cert to person or webhosting or both and in the root 

---------------------------------------------------

In the MMC (run as admin), Certificates

Friendly name=server name

Click on subject tab and fill this in:

Subject name:

Common Name = ServerName

Organizational unit = Web

Organization = DSHS/CATS

Locality = Olympia

State = WA

Country = US

Alternate name:

DNS = ServerName

IPV4 : IP Address of the Server

Private key tab

expand key options

                key size=2048

                make private key exportable

Click ok, next, save file

For the Back end Server, please follow this process to request a certificate

Login to backend server

1.       Open IIS

2.       On the Main node, double click on the Server Certificate

3.       Create Certificate request

a.       Common Name : IP Address of the Server.

b.       Organization = DSHS/CATS

c.       Organizational unit = Web

d.       Locality = Olympia

e.       State = WA

f.        Country = US

4.       Click Next

5.       Cryptographic provider :  Don’t change any thing.

a.       Bit Length : 2048

6.       Click Next

7.       Give a filename and save on the desktop or any folder as you like and send the save file for cert generation.

async and await call

from http://blog.stephencleary.com/2013/11/taskrun-etiquette-examples-dont-use.html

Last time we looked at using Task.Run for the wrong thing (code that is not CPU-bound). So let’s move on to the proper use case of Task.Run: CPU-bound code. We start off with some existing code, which synchronously does some heavy calculations.

class MyService
{
  public int CalculateMandelbrot()
  {
    // Tons of work to do in here!
    for (int i = 0; i != 10000000; ++i)
      ;
    return 42;
  }
}

...

private void MyButton_Click(object sender, EventArgs e)
{
  // Blocks UI thread! :(
  myService.CalculateMandelbrot();
}

Now, we want to use this from a UI thread, but this method will block our thread. This is a problem that should be solved using Task.Run. Doing these calculations is a CPU-bound operation.

// Warning: bad code!
class MyService
{
  public Task<int> CalculateMandelbrotAsync()
  {
    return Task.Run(() =>
    {
      // Tons of work to do in here!
      for (int i = 0; i != 10000000; ++i)
        ;
      return 42;
    });
  }
}

...

private async void MyButton_Click(object sender, EventArgs e)
{
  // Does not block UI thread! Yay!
  await myService.CalculateMandelbrotAsync();
}

At first glance, it may look like this solves the problem. And it does solve thisproblem, but it does not do it in the best way.

Let’s say that this service is a generic dll that can be used inside any .NET application. It has an API, and APIs are all about etiquette.

How would an ASP.NET application react to this change?

Let’s introduce a simple ASP.NET MVC controller that returns a view using the (original, synchronous) service.

class MyService
{
  public int CalculateMandelbrot()
  {
    // Tons of work to do in here!
    for (int i = 0; i != 10000000; ++i)
      ;
    return 42;
  }
}

...

public class MandelbrotController: Controller
{
  public ActionResult Index()
  {
    var result = myService.CalculateMandelbrot();
    return View(result);
  }
}

So far, so good. When a request comes in, the controller uses the service to (synchronously) calculate the view data. A single request thread is used the entire time during that calculation.

But the desktop app required a change in the service. It’s now async, which is “no problem” because ASP.NET MVC naturally supports asynchronous actions.

// Warning: bad code!
class MyService
{
  public Task<int> CalculateMandelbrotAsync()
  {
    return Task.Run(() =>
    {
      // Tons of work to do in here!
      for (int i = 0; i != 10000000; ++i)
        ;
      return 42;
    });
  }
}

...

public class MandelbrotController: Controller
{
  public async Task<ActionResult> IndexAsync()
  {
    var result = await myService.CalculateMandelbrotAsync();
    return View(result);
  }
}

And when we do testing, it works! Unfortunately, this change introduced a performance problem.

With the original (synchronous) code, only one thread was used to process the request, from beginning to end. That’s a heavily-optimized ASP.NET scenario. With this async code using Task.Run, instead of a single request thread, this is what happens:

• The request starts processing on an ASP.NET thread.
• Task.Run starts a task on the thread pool to do the calculations. The ASP.NET thread pool has to deal with (unexpectedly) losing one of its threads for the duration of this request.
• The original request thread is returned to the ASP.NET thread pool.
• When the calculation is complete, that thread completes the request and is returned to the ASP.NET thread pool. The ASP.NET thread pool has to deal with (unexpectedly) getting another thread.

This will work correctly, but it’s not at all efficient.

There are (at least) four efficiency problems introduced as soon as you useawait with Task.Run in ASP.NET:

• Extra (unnecessary) thread switching to the Task.Run thread pool thread. Similarly, when that thread finishes the request, it has to enter the request context (which is not an actual thread switch but does have overhead).
• Extra (unnecessary) garbage is created. Asynchronous programming is a tradeoff: you get increased responsiveness at the expense of higher memory usage. In this case, you end up creating more garbage for the asynchronous operations that is totally unnecessary.
• The ASP.NET thread pool heuristics are thrown off by Task.Run“unexpectedly” borrowing a thread pool thread. I don’t have a lot of experience here, but my gut instinct tells me that the heuristics should recover well if the unexpected task is really short and would not handle it as elegantly if the unexpected task lasts more than two seconds.
• ASP.NET is not able to terminate the request early, i.e., if the client disconnects or the request times out. In the synchronous case, ASP.NET knew the request thread and could abort it. In the asynchronous case, ASP.NET is not aware that the secondary thread pool thread is “for” that request. It is possible to fix this by using cancellation tokens, but that’s outside the scope of this blog post.

If you have multiple calls to Task.Run, then the performance problems are compounded. On a busy server, this kind of implementation can kill scalability.

That’s why one of the principles of ASP.NET is to avoid using thread pool threads (except for the request thread that ASP.NET gives you, of course). More to the point, this means that ASP.NET applications should avoidTask.Run.

Whew! OK, so now we know what the problem is with that implementation. The plain fact is that ASP.NET prefers synchronous methods if the operation is CPU-bound. And this is also true for other scenarios: Console applications, background threads in desktop applications, etc. In fact, the only place we really need an asynchronous calculation is when we call it from the UI thread.

But watch out! There’s another pitfall just ahead…

Using Task.Run for Asynchronous Wrappers

Let’s continue the “Mandelbrot” example. We’ve learned that some clients prefer asynchronous APIs for CPU-bound code and others prefer synchronous APIs for CPU-bound code.

So, let’s be good API citizens (“APIs are all about etiquette”) and keep the new synchronous version along with the asynchronous version. That way there’s no breaking changes, right? It’s simple enough, and we can even implement it easily so that there’s no code duplication!

// Warning: bad code!
class MyService
{
  public int CalculateMandelbrot()
  {
    // Tons of work to do in here!
    for (int i = 0; i != 10000000; ++i)
      ;
    return 42;
  }

  public Task<int> CalculateMandelbrotAsync()
  {
    return Task.Run(() => CalculateMandelbrot());
  }
}

Sweet. The UI app has its nice asynchronous method, and the ASP.NET app has its original synchronous method. Easy! And there are many other examples where synchronous and asynchronous APIs exist side-by-side, so developers are already used to this! But the fact is that using Task.Run for asynchronous wrappers is a code smell.

The problem with this approach is what is implied by this API design. Consider all the examples where synchronous and asynchronous APIs exist side-by-side, e.g., Entity Framework 6, or the WebClient class. Notice anything? They’re all naturally asynchronous! Not a single one of them is CPU-bound.

When a developer sees two methods in an API Method and MethodAsync, the convention is that they represent a naturally-asynchronous operation. In other words, the developer expects that MethodAsync is the “natural” implementation and that Method is essentially a synchronous (blocking) equivalent of that operation. That API implies that Method will at some point have the calling thread enter a wait state as it blocks for the naturally-asynchronous operation to complete.

Let’s make this a bit more practical. When a new ASP.NET developer approaches our service API, they’ll see CalculateMandelbrot andCalculateMandelbrotAsync (and let’s pretend that our method names are not so obviously CPU-bound). If they’re familiar with asynchronous APIs at all, they’ll assume that this calculation is naturally asynchronous. And on ASP.NET, you should use naturally-asynchronous methods. Therefore, they will choose what they think is the naturally-asynchronousCalculateMandelbrotAsync method and end up inheriting the performance problems discussed earlier.

CalculateMandelbrotAsync is what I call “fake-asynchronous” because it’s just a thread pool wrapper around a synchronous operation. But when developers see that API, they assume that it is a naturally-asynchronous operation.

This is just a brief description and I only covered one facet of this problem. Stephen Toub has an excellent blog post explaining in detail why you should not write asynchronous wrappers for synchronous methods.

OK, enough about the wrongsolutions? How do we fix this theright way???

Back up to the original problem for a moment. What is the problem? The UI thread is blocked. How did we solve it? By changing the service. Who needs the asynchronous API? Only the UI thread. Sounds like we just seriously violated the “Separation of Concerns” principle.

The key here is that the solution does not belong in the service. It belongs in the UI layer itself. Let the UI layer solve its own problems and leave the service out of it.

class MyService
{
  public int CalculateMandelbrot()
  {
    // Tons of work to do in here!
    for (int i = 0; i != 10000000; ++i)
      ;
    return 42;
  }
}

...

private async void MyButton_Click(object sender, EventArgs e)
{
  await Task.Run(() => myService.CalculateMandelbrot());
}

Now the service API is clean (it exposes a synchronous API for a naturally-synchronous, CPU-bound method), it works for all consumers (e.g., ASP.NET), and the UI layer is responsible for not blocking the UI thread.

Conclusion: do not use Task.Run in the implementation of the method; instead, use Task.Run to call the method.