Showing posts with label SSL. Show all posts
Showing posts with label SSL. Show all posts

Monday, May 29, 2023

Run ASP.Net Core Web API on Kestrel dev web server with https on Windows

In this post I will describe how to run ASP.Net Core Web API on Kestrel development web server under https. First of all we need to create self-signed SSL certificate. We may generate it with PowerShell (see Use self-signed SSL certificate for web API hosted in Azure App service) or openssl tool:

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout test.key -out test.crt -config test.conf -passin pass:123
openssl pkcs12 -export -out test.pfx -inkey test.key -in test.crt -passout pass:123

For running above commands we will need config file test.conf with information about domain name. It may look like that:

[req]
default_bits = 2048
default_keyfile = test.key
distinguished_name = req_distinguished_name
req_extensions = req_ext
x509_extensions = v3_ca

[req_distinguished_name]
countryName =
countryName_default =
stateOrProvinceName =
stateOrProvinceName_default =
localityName =
localityName_default =
organizationName = Test
organizationName_default = Test
organizationalUnitName = organizationalunit
organizationalUnitName_default = Development
commonName = api.example.com
commonName_default = api.example.com
commonName_max = 64

[req_ext]
subjectAltName = @alt_names

[v3_ca]
subjectAltName = @alt_names

[alt_names]
DNS.1 = api.example.com

Once private key (pfx) is created we may install it to the local certificates store: double click pfx, and follow certificate installation wizard with default settings:


We will also need to provide password for private key in this wizard (in above example "123").

Once certificate is installed to the certificates store we need to set the following parameters in appsettings.json file of our ASP.Net Core Web API project:

{
  "Kestrel": {
    "Endpoints": {
      "Http": {
        "Url": "http://api.example.com:5057"
      },
      "HttpsInlineCertStore": {
        "Url": "https://api.example.com:5058",
        "Certificate": {
          "Subject": "api.example.com",
          "Store": "My",
          "Location": "CurrentUser",
          "AllowInvalid": true
        }
      }
    }
  }
}

(since in our example self-signed certificate is used we need to set AllowInvalid: true parameter). If everything is done correctly Web API will run on local Kestrel dev server under https.

Friday, October 15, 2021

Convert self-signed SSL certificate's private key from .pfx to .key and .crt

Some time ago I wrote a post how to use self-signed SSL certificate in Azure App service: Use self-signed SSL certificate for web API hosted in Azure App service. In this article we generated self-signed certificate, exported private key to pfx file and used it in Azure. But what it you will use another hosting provider which require private key in .key format and SSL certificate itself in .crt file? Good news is that it is possible to create .key/.crt files from .pfx and in this article I will show how to do that.

We will need openssl.exe tool which will make actual work. If you will try to Google it there will be plenty of 3rt party sites where you may download that. The problem however is that there is no guarantee that these are safe download links (i.e. that there won't be malwares and viruses). Safer option is to use openssl.exe which is shipped with git client for Windows: I found my in the following location:

C:\Program Files\Git\usr\bin\openssl.exe

With this tool in order to export SSL certificate from .pfx to .crt we may use the following command:

openssl pkcs12 -in myCert.pfx -clcerts -nokeys -out myCert.crt

and in order to export private key to .key format from .pfx the following:

openssl pkcs12 -in myCert.pfx -nocerts -out myCert-encrypted.key

Here you will need to specify pfx password and also provide so called PEM pass phrase which will proteck .key file. I.e. private key in .key format will be still encrypted. If you will need it in unencrypted format (ensure that it will be stored in safe location in this case) use the following command:

openssl rsa -in myCert-encrypted.key -out myCert-decrypted.key

After that you will be able to use self-signed SSL certificate in .key/.crt format.

If you need certificate in.pem format you may get it by concatenating myCert-decrypted.key and myCert.crt files - resulting .pem file should have the following parts (first is copied from myCert-decrypted.key and second from myCert.crt):

-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

So if your hosting provider requires .pem file you will be able to use it there.

Friday, October 1, 2021

Use self-signed SSL certificate for web API hosted in Azure App service

Suppose that we develop web API (e.g. https://api.example.com) and want to use self-signed certificate for it's domain name. Since it is web API we usually don't worry a lot about errors or warning which browser may show when you try to access it by url there. At the same time we don't want to compromise security and thus want to allow only our SSL certificate with known hash/thumbprint.

First of all we need to create self-signed certificate for domain name which will be used for web API (it should contain CN=api.example.com otherwise it won't be possible to bind it to custom domain name in Azure App service). Also certificate should be created with exportable private key (pfx) so we can use it in Azure. It can be done by the following PowerShell:

$start = [System.DateTime]::Now.AddDays(-1)
$end = $start.AddYears(2)
New-SelfSignedCertificate `
    -FriendlyName "api.example.com" `
    -KeyFriendlyName "api.example.com" `
    -KeyAlgorithm "RSA" `
    -DnsName "api.example.com" `
    -NotBefore $start `
    -NotAfter $end `
    -KeyUsage CertSign, CRLSign, DataEncipherment, DigitalSignature, NonRepudiation `
    -KeyUsageProperty All `
    -KeyLength 2048 `
    -CertStoreLocation cert:\LocalMachine\My `
    -KeyExportPolicy Exportable
$cert = Get-ChildItem -Path Cert:\LocalMachine\my | where-object { $_.Subject -eq "CN=api.example.com" }
$password = Read-Host -Prompt "Enter Password to protect private key" -AsSecureString
Export-PfxCertificate -Cert $cert -Password $password -FilePath api.example.com.pfx

Here we first create certificate itself and then export it's private key to file system.

Next step is to add custom domain name api.example.com to Azure app service where we will host our API. First of all we need to ensure that current pricing tier supports "Custom domains / SSL" feature. Currently minimal pricing tier with this option is B1 (it is not free):

Then we go to App service > Custom domains > Add custom domain and specify desired domain name for our web API:

Before Azure will allow to use custom domain name we will need to prove hostname ownership by adding TXT and CNAME DNS records for specified domain name - it is done in hosting provider control panel (here are detailed instructions of the whole process: Map an existing custom DNS name to Azure App Service).

Last part is related with client which call our web API. Since web API uses self-signed certificate attempt to call it from C# using HttpClient will fail. We need to configure it to allow usage of our SSL certificate but at the same time don't allow to use other self-signed SSL certificates. It can be done with the following C# code:

// thumprint of self-signed SSL certificate
private const string CERT_THUMBRINT = "...";

ServicePointManager.ServerCertificateValidationCallback = validateServerCertficate;
...
private static bool validateServerCertficate(
    object sender,
    X509Certificate cert,
    X509Chain chain,
    SslPolicyErrors sslPolicyErrors)
{
    if (sslPolicyErrors == SslPolicyErrors.None)
    {
        // Good certificate.
        return true;
    }

    return string.Compare(cert.GetCertHashString(), CERT_THUMBRINT, true) == 0;
}

In this code we instruct ServicePointManager to allow only our self-signed certificate (if error occurred during checking of SSL certificate when connection to remote host is established). Those it won't allow connections to hosts which use other self-signed SSL certificates.

Update 2021-10-15: see also post Convert self-signed SSL certificate's private key from .pfx to .key and .crt which describes how to export private key of self-signed certificate from pfx to key/crt.

Wednesday, March 28, 2018

Avoid problem with redirecting Sharepoint sites which use .dev sub domains to https in Chrome and Firefox

As you probably heard some time ago Chrome and FF started to redirect sites which use .dev sub domains in URL to https. Issue is described e.g. here: Chrome & Firefox now force .dev domains to HTTPS via preloaded HSTS. Briefly .dev domain is owned by Google and they added HSTS rule for it which forces redirection to https. You may check it in Chrome: open chrome://net-internals#hsts and make query for dev domain:

2018-03-28_16-38-32

As you can see there is FORCE_HTTPS rule.

This problem may occur in local dev Sharepoint environments which often use .dev domain. So if you have e.g. site http://intranet.sp.dev and will try to open it in Chrome or Firefox it won’t open it with unclear error:

2018-03-28_16-37-56

But if you notice url address bar of the browser you will find that it actually tries to open https://intranet.sp.dev instead of http://intranet.sp.dev and it causes issue. You may try to add https binding to the site using self-signed certificate, but browser will still show error that connection is not secure.

The following solution may be used for avoiding this problem with Sharepoint site. It requires using new site address http://intranet.sp.local for your Sharepoint site instead of http://intranet.sp.dev:

  • add intranet.sp.local binding for your Sharepoint site in IIS Manager
  • in C:/Windows/System32/drivers/etc/host add
      127.0.0.1 intranet.sp.local
  • in Central administration > Alternate access mappings > Add internal url for not used zone: http://intranet.sp.local

After that site can be opened in Chrome and FF using http://intranet.sp.local url.

Saturday, October 28, 2017

Configure several SSL sites on single IP in IIS with SNI

As you probably know the classic way to configure https site in IIS is to add site binding for 443 port on specific IP address with SSL certificate. This approach works but the problem is that you may have only 1 https site per IP address. If you would try to create second site on the same IP the following message is shown:

At least one other site is using the same HTTPS binding and the binding is configured with a different certificate. Are you sure that you want to reuse this HTTPS binding and reassign the other site or sites to use the new certificate?

In order to create more https sites additional IP addresses are required. In turn it adds more maintenance efforts, firewalls configurations, etc.

Currently in IIS there is more convenient way which allows to create multiple https sites on the same IP address: Server Name Indication or SNI. SNI support was added to IIS from version 8 and all major browsers support it several years already (see Server Name Indication).

With SNI when you create SSL binding on IP address which is already used for other https site you have to check checkbox “Server Name Indication” and specify domain name which will be used for identifying the site:

There won’t be warnings and binding will be created successfully.

Tuesday, January 26, 2016

Fast way to find mixed http content on https sites

When your site is accessed through https and have content which is loaded using http protocol (e.g. images, iframes or javascript files) you will have either this content blocked or will see warning, e.g. like in IE “Only secure content is displayed”:

Fastest way to find exact resource which caused this issue is to use Developer tools available in all modern browsers (by default click F12). In console tab you will see what caused this problem:

IE:

FF:

Chrome:

Wednesday, November 6, 2013

Unsecure content inside iframe page

Suppose that you have site A and site B. Site A is accessible through https, and you want to integrate site B to it via iframe. In order to avoid “Only secure content is displayed” message and blocking site B in the browser, site B should be accessible also via https:

   1: <iframe src="https://siteB.com" style="height: 200px; width: 100%"></iframe>

But it is not enough. If on site B page, which is shown in iframe, there will be any http links (e.g. js files included via http), you will again get “Only secure content is displayed” message, although this time site B won’t be blocked. Instead part of it will be shown in iframe immediately, but full page will be shown only when user will click Show all content button:

image

If you want to avoid this message completely, both site B should be access through https and content inside site B should have only https links.