Common Core

Connection Security with TLS

The configuration just created uses a self-signed certificate (Figure 2). To bind a trusted certificate to the Kestrel instance, it must be configured slightly differently at startup. Instead of the simple specifications in .UseStartup(), as described above, you need to adjust the CreateHostBuilder function as shown in Listing 1.

01 public static IHostBuilder CreateHostBuilder(string[] args) =>
02   Host.CreateDefaultBuilder(args)
03     .ConfigureWebHostDefaults(webBuilder =>
04     {
05       webBuilder.ConfigureKestrel(serverOptions =>
06        {
07          serverOptions.ListenAnyIP(4711,
08           listenOptions => {
09            listenOptions.UseHttps("cert.pfx", "<password>");
10           }
11          );
12        })
13        .UseStaticWebAssets()
14        .UseStartup<Startup>();
15     });

Figure 2: SSL-encrypted traffic with a trusted certificate is a must-have.

Much like site bindings on the IIS, the port listened on and the certificate to be used are defined as parts of the same configuration. The PFX file with the TLS certificate must be located in the root directory of the web application. The password is in plain text in the C# file; therefore, it is important that unauthorized persons do not gain access to this file.

The listenOptions class has many properties that can be used to influence the behavior of the Kestrel Worker [3]. The storage path of the PFX file is important later when you run the fully compiled application on a server without the .NET Core SDK. The path is always relative to the defined working directory. You should not confuse this with the location of the compiled web application.

The UseStaticWebAssets method indicates that, in addition to the content generated by the application, static web content such as CSS stylesheets, graphics files, and browser scripts should be delivered, as well. By default, these are located in the wwwroot directory – also relative to the current working directory.

Doing Without Windows Components

To develop your .NET Core application, you can use Microsoft's proven Visual Studio, which is available for free as the Community Edition – as long as you do not create applications for organizations with more than 1,000 users. If you select the Web Development Component, you will find many project templates for .NET Core and ASP.NET Core (Figure 3).

Figure 3: Visual Studio offers numerous .NET Core project templates in the Community Edition.

To begin, develop your application in the usual way and make sure you do not include any components specific to Windows. When the application is ready, compile it for the target platform. You will need either a Linux machine with the .NET Core SDK installed or a Linux instance in the Windows Subsystem for Linux (WSL), also with the .NET Core SDK on board.

Next, copy the source code of your application to the Linux instance, change to the project directory, and run:

dotnet build

By default, a debug build is generated; if you want a release build, specify -c Release as a parameter. The result will end up, as in Windows, in /bin/Debug/netcoreapp3.1 or /bin/Release/netcoreapp3.1. After copying the static files from wwwroot and other content such as PFX files into the build directory, and you will have a ready-to-run application that you can execute on a Linux machine without a .NET-Core SDK – you only need the correct version of the runtime. The file to be executed has a DLL extension, which is not typical for Linux.

You can and will want to automate the process of taking the necessary files and directories with you by adding all necessary components to your Visual Studio project and then starting the build process with:

dotnet publish -c Release

You will find the complete app in /bin/Release/netcoreapp3.1/publish.

Launch the Apps

Unlike the pool of applications on IIS, with launching and lifecycles managed by the WWW Publishing Service, a Kestrel web application is a standalone process and is not controlled by anything. If you want your new web application to launch automatically when the server is restarted, you need to take action yourself and register the application as a service. You need to create a service user for the service first if a suitable account does not already exist on your Linux server:

sudo add user netcoreapp01

Then, copy the application from your build machine to the home directory of the service user. You can also use another directory (e.g., /var/www), but then you have to grant the service user read and execute permissions manually. Now create the service object for your service, such as

sudo nano /etc/systemd/system/netcoreapp01.service

(but with the editor of your choice). The file must have at least the content shown in Listing 2.

[Unit]
Description=My first .NET Core web app
[Service]
WorkingDirectory=/home/netcoreapp01
ExecStart=/usr/bin/dotnet /home/netcoreapp01/netcoreapp01.dll
Restart=always
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=netcoreapp01
User=netcoreapp01
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false
[Install]
WantedBy=multi-user.target

Next, save the file and check whether the service starts:

sudo systemctl start netcoreapp01

You can view the result the same way but with the status instead of the start command. If everything works as desired, set up an automatic start, again with the same format, but with the enable command.

Now your application will load automatically, even after a server reboot.