Newest KB Articles

Purchasing an SSL certificate from a third-party provider

Fri, 27 Feb 2026 19:47:47 GMT

Introduction

This article outlines the general steps for obtaining an SSL certificate from a third-party provider and installing it on your website using the control panel.

You will first generate a CSR (Certificate Signing Request) on your computer. This CSR is submitted to your chosen SSL provider. The CSR is required for the SSL Provider to issue your certificate. Once the certificate has been issued, you will export the certificate as a PFX file. You will then upload this PFX file to your control panel, where it can be used for installation on your site.

NOTE: We understand that some customers prefer to manage their SSL certificates independently. If you’re looking for a more streamlined process, you also have the option to purchase an SSL certificate through us. In most cases, we handle the setup and installation, which usually requires little to no action on your part.

What Is a CSR and Why Do I Need One?

A CSR (Certificate Signing Request) is a small file you generate on your computer. Think of it like a job application form. It contains information about your website and your company. When you want to buy an SSL certificate from a third-party provider (like GoDaddy, Namecheap, or another CA), they need this file from you in order to create your certificate.

Once they have your CSR, they will verify your information and issue your SSL certificate. You will then need to install that certificate. This guide walks you through the whole process, step by step.

What You Will Need Before You Start

A Windows computer (Windows 10 or Windows 11 is fine).
IIS (Internet Information Services) — this is a free feature that comes with Windows. It is not turned on by default, but we will show you how to turn it on below.
The domain name you want to secure (for example, www.yoursite.com).
Basic information about your company (name, city, state, country).

Step 1 — Turn On IIS (If You Have Not Already)

IIS is a built-in Windows feature that is usually turned off. Here is how to turn it on:

Click the Start button (the Windows logo in the bottom-left corner of your screen).
Type Turn Windows features on or off and click on it when it appears.

In the list that appears, look for Internet Information Services. Check the box next to it.
Click OK and wait for Windows to finish. This may take a couple of minutes.

Tip: If the box next to Internet Information Services is already checked, IIS is already installed and you can skip to Step 2.

Step 2 — Open IIS Manager

Click the Start button and type IIS or Internet Information Services Manager.
Click on Internet Information Services (IIS) Manager to open it.

Step 3 — Create the Certificate Request (CSR)

This is where you generate the CSR file that you will send to the SSL certificate provider.

In IIS Manager, look at the left-hand side panel. Click on your computer's name (it will be at the very top of the list).
In the middle section, look for an icon called Server Certificates. Double-click on it.

On the right-hand side, click Create Certificate Request... A window will open asking for your information.

Fill in each field as follows (do not worry — it is just basic information about you and your website):

Field	What to Enter
Common Name	The full domain name you want to secure. Example: www.yoursite.com. If you want a Wildcard certificate that covers all subdomains, use *.yoursite.com.
Organization	The legal name of your business or organization. If you are an individual, you can use your full name.
Organizational Unit	The department handling this. If you are unsure, you can type IT or just your company name again.
City / Locality	The city where your organization is located.
State / Province	Your state or province. Spell it out fully (example: California, not CA).
Country	The two-letter country code. For the United States, enter US.

Click Next. On the next screen, you will see a Cryptographic Service Provider and a Bit Length. Leave these settings as they are (the defaults are fine) and click Next again.
On the last screen, you will be asked to save the file. Click the ... button to choose where to save it. Save it somewhere easy to find, such as your Desktop. Name it something you will recognize, like mysite_csr.txt.
Click Finish. Your CSR file has been created and saved!

Tip: Do not delete or move this file after you save it. You will need it in the next step.

Step 4 — Submit Your CSR to Your SSL Provider

Now that you have your CSR file, it is time to purchase your SSL certificate from a third-party provider (such as GoDaddy, Namecheap, Comodo, or any other provider of your choice).

Open the CSR file you saved in the previous step. You can do this by right-clicking the file and selecting Open with > Notepad.
You will see a block of text that starts with -----BEGIN CERTIFICATE REQUEST----- and ends with -----END CERTIFICATE REQUEST-----. Select all of this text and copy it (Ctrl + A, then Ctrl + C).
Go to your SSL provider's website and start the SSL certificate purchase process. When they ask for your CSR, paste the text you copied into the box they provide.
Complete the purchase and follow any verification steps your provider requires. They will email you when your certificate is ready.

Note: Every SSL provider is a little different. If you are not sure where to paste the CSR, look for a step in their checkout or order process labeled 'Enter CSR' or 'Configure Certificate'.

Step 5 — Complete the Certificate Installation in IIS

Once your SSL provider emails you the certificate, you will need to complete the installation in IIS. This connects the certificate to the request you made earlier.

Save the certificate file your provider sent you to your computer (usually a .crt or .cer file).
Open IIS Manager again and go back to Server Certificates (same as Step 2).
On the right-hand side, click Complete Certificate Request...
Click the ... button to browse to the certificate file you saved. Give it a friendly name you will recognize (for example, MySiteSSL) and click OK.

Your certificate is now installed in IIS. The next step is to export it as a PFX file so you can upload it to Winhost.

Step 6 — Export the Certificate as a PFX File

Winhost needs the certificate in a specific format called PFX (also known as PKCS#12). This file bundles your certificate together with its private key. Here is how to export it:

In IIS Manager, go back to Server Certificates. Find the certificate you just installed in the list.
Click on it once to select it, then on the right-hand side click Export...
Choose where to save the file and give it a name (for example, mysite_certificate.pfx). You will also be asked to create a password — write this down, as you will need it when uploading to Winhost.
Click OK. Your PFX file is now saved on your computer.

Step 7 — Upload the PFX to Winhost

The last step is to upload your PFX file to the Winhost Control Panel so it can be installed on your site.

Log in to your Winhost Control Panel and go to Sites > [your domain] > SSL Manager.
Click Upload PFX.
Browse for the PFX file you exported in Step 6 and enter the password you created for it.
Click Upload to install the certificate on your site. That's it!

Note: After your certificate is installed, remember to set up a forced HTTPS redirect so visitors always use the secure version of your site. See the Force HTTPS with URL Rewrite knowledge base article for instructions.

Note: If you run into any trouble at any step, contact Winhost Support. Have your domain name and the step number from this guide ready — it will help us assist you faster.

Client Authentication Extended Key Usage (EKU)

Sat, 07 Feb 2026 21:52:05 GMT

Overview

Client Authentication Extended Key Usage (EKU) is a certificate attribute that allows an SSL/TLS certificate to be used for client authentication, most commonly in mutual TLS (mTLS) scenarios.

In mTLS, both sides authenticate each other:

The server presents a server certificate
The client application presents a client certificate containing the Client Authentication EKU

This is commonly used for:

Secure API integrations
Partner gateways
Financial and insurance systems
Zero-trust architectures

What Is Client Authentication EKU?

Extended Key Usage (EKU) defines what a certificate is allowed to be used for.

The Client Authentication EKU is identified as:

1.3.6.1.5.5.7.3.2 (Client Authentication)

A certificate containing this EKU can:

Identify a client application
Be presented during the TLS handshake
Be validated by the remote server as a trusted client

Without this EKU, the certificate cannot be used for mTLS client authentication.

Industry Change: Public SSL Certificates No Longer Support Client Authentication EKU

Due to industry-wide security and browser root program changes, public Certificate Authorities no longer issue SSL/TLS certificates that include Client Authentication EKU.

This affects:

Sectigo
DigiCert
RapidSSL
Other publicly trusted CAs

As a result:

Public website SSL certificates are now Server Authentication only
Client Authentication EKU is no longer available in public SSL certificates
IIS hosting providers cannot install or issue such certificates

This is expected behavior and not a hosting limitation.

Supported Alternative: Private PKI Client Certificates

For mTLS and client authentication, the supported solution is to use a Private PKI client certificate.

Key differences

Public SSL	Private PKI Client Certificate
Website HTTPS	Application identity
Installed in IIS	Loaded by application code
Publicly trusted	Trusted by specific partner
No clientAuth EKU	Includes clientAuth EKU

How to Use a Private PKI Client Certificate on Shared IIS Hosting

On shared IIS servers:

Certificates cannot be installed into the Windows certificate store
IIS does not manage outbound client certificates

Instead, the certificate is used directly by the application.

Recommended Setup

1. Store the certificate securely

Upload the PFX file to a non-public folder such as:

/App_Data/cert.pfx

Ensure:

The file is not web-accessible
The password is stored securely (config file, environment variable, or secret store)

2. Load the certificate in application code

The application loads the certificate only when making outbound HTTPS calls.

Example: .NET / ASP.NET (HttpClient)

using System.Net.Http;
using System.Security.Cryptography.X509Certificates;
var certPath = Server.MapPath("~/App_Data/cert.pfx");
var certPassword = "your-pfx-password";
var clientCert = new X509Certificate2(
    certPath,
    certPassword,
    X509KeyStorageFlags.MachineKeySet
);
var handler = new HttpClientHandler();
handler.ClientCertificates.Add(clientCert);
using var client = new HttpClient(handler);
// Example API call
var response = await client.GetAsync("https://api.partner.com/endpoint");

This:

Sends the client certificate during the TLS handshake
Enables mTLS authentication
Requires no IIS configuration

3. Partner establishes trust

The external system (e.g., API gateway):

Registers the public portion of the certificate
Trusts inbound requests signed by that certificate

Local “Not Trusted” warnings are expected for Private PKI certificates.

What You Do NOT Need to Do

❌ Do not install the certificate as a website SSL
❌ Do not add IIS bindings
❌ Do not replace your public HTTPS certificate
❌ Do not enable IIS client certificate authentication

Summary

Client Authentication EKU enables mTLS client identity
Public SSL certificates no longer support this EKU
This is an industry-wide change
Private PKI client certificates are the correct solution
On shared IIS hosting, the certificate is loaded by application code
IIS configuration is not required

Known issues related to new EU Data Center Migration

Fri, 19 Dec 2025 18:22:28 GMT

Known Issues After Migration to the New EU Data Center

SMTP connections to external mail servers

If your application sends email through an external SMTP server (that is, not using localhost) over port 25, you may encounter connection errors after migration.

This occurs because our new data center provider blocks outbound port 25 traffic to help prevent spam abuse.

Resolution:

Update your application to use the SMTP Submission port instead.

Recommended port: 587

MIME type configuration errors

If your application defines MIME types in web.config without first removing existing entries, you may receive configuration errors.

This happens because the new servers may already have the MIME type defined at the system level.

Resolution:

Modify your web.config to remove the MIME type before adding it.

Example:

<remove fileExtension=".woff2" /> 
<mimeMap fileExtension=".woff2" mimeType="font/x-woff" />

MySQL ODBC driver compatibility

If your ASP or ASP.NET application connects to a MySQL database using the MySQL ODBC driver, you may experience errors after migration.

The new servers use the MySQL ODBC 5.3 driver, while the previous servers may have used version 5.1 or 5.2. MySQL ODBC drivers do not support side-by-side installation, which can cause driver mismatch issues.

Resolution:
Update your database connection string to reference one of the following drivers:

{MySQL ODBC 5.3 Unicode Driver}
{MySQL ODBC 5.3 ANSI Driver}