Publishing and Hosting Apps Developed in SnapDevelop

Last Updated: February 2021

Overview

SnapDevelop provides the following methods to publish your projects:

• File System: Publishes to a local folder.
• Web Deploy: Publishes to an IIS server.
• Docker: Publishes with Docker.

The following table lists the project types you can publish with SnapDevelop, as well as the supported publish methods and their results.

Project Type	Methods	Results
ASP.NET Core Web API	File System	Application files are created in the target folder and ready for deployment.
	Web Deploy	Application is deployed to the target web server.
	Docker	Application image is deployed to the target Docker registry.
Console App (.NET Core)	File System	Application files are created in the target folder and ready for deployment.
Class Library (.NET Core)	File System	All library assembly files, including their dependency files, are created in the target folder.
Class Library (.NET Standard)	File System	All library assembly files, including their dependency files, are created in the target folder.

Publishing to a Local Folder

This topic describes how to publish a project to a local folder with SnapDevelop.

To publish a project to a local folder

1. In the Solution Explorer, right click on the project node, and select Publish.

2. In the window that appears, select the File System tab, and click Start.

3. Browse to and select a folder as the publish target, and click Next.

4. Configure the publish profile, and click Finish.

   Setting	Description
   Configuration	Select a build configuration.
   Target Framework	Select the target framework.
   Deployment Mode	Publishing your app as Self-Contained produces an application that includes the .NET Core runtime and libraries, and your application and its dependencies. Users of the application can run it on a machine that doesn't have the .NET Core runtime installed. Publishing your app as Framework-Dependent produces an application that includes only your application itself and its dependencies. Users of the application have to separately install the .NET Core runtime.
   Target Runtime	Select the target runtime.
   Delete all existing files prior to publish	Delete all the files in the target folder before publishing.
   Use this connection string at runtime	When it is selected, the publish process changes the connection string for this database in the deployed Web.config file to the value you specify in the textbox.

   The publish process starts after you click Finish. You can view the publish progress in the Output window.

Publishing to IIS

This topic describes how to publish a project to IIS with SnapDevelop. It also includes troubleshooting information for some common errors.

Prerequisites

Both the server and client side requirements must be met before you publish a project to IIS.

Server Side Requirements

• Windows Server 2019, 2016, or 2012

  If your operating system is Windows 10, you can use File System, rather than Web Deploy, to publish your project to your local folder.

  Make sure that your Windows is up-to-date and includes KB2999226, otherwise you might see this error when you launch a .NET Core application: The program can't start because api-ms-win-crt-runtime-1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem.

• Web Deploy 3.6 or higher

  Download link: https://www.iis.net/downloads/microsoft/web-deploy

  When you install Web Deploy, select the Complete setup type to install.

• Hosting Bundle

  Download link: https://dotnet.microsoft.com/download/dotnet-core

  Download and install the ASP.NET Core Hosting Bundle. Make sure that the version of ASP.NET Core Hosting Bundle is the same as the framework version your project targets. For example, if your project targets .NET Core 3.1, install the Hosting Bundle version 3.1.

Client Side Requirements

• Windows 10/8.1

  Make sure that your Windows is up-to-date and includes KB2999226, otherwise you might see this error when you launch a .NET Core application: The program can't start because api-ms-win-crt-runtime-1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem.

• Web Deploy 3.6 or higher

  The Web Deploy on the client side is automatically installed when you install SnapDevelop.

Configuring Server Side

Configuring IIS

To configure IIS

1. Launch the Server Manager.

2. Use the Add Roles and Features wizard from the Manage menu or the link in Server Manager. On the Server Roles page, select the Web Server (IIS) and Management Tools checkboxes.

   

3. On the Features page, select the .NET Framework 3.5 Features and .NET Framework 4.6 Features checkboxes.

   

4. Confirm the roles and features you selected, and click Install.

   

Configuring Web Deploy

You must enable the Web Management Service and Web Deployment Agent Service after installing Web Deploy.

To enable the services

1. Launch the desktop application Services.

2. Locate Web Management Service and Web Deployment Agent Service. Right click on each of them, and select Start.

   

Enabling Remote Connections

To enable remote connections

1. Launch the IIS Manager.

2. Select your computer in the Connections panel first, and then double click Management Service on the right.

   

3. In the Management Service, click Stop first, then select the Enable remote connections checkbox, and click Apply.

   

Adding IIS Users

You can add IIS users of IIS Manager type or Windows type.

Adding IIS Manager Users

To add IIS Manager users

1. In the IIS Manager, select your computer in the Connections panel, and then double click IIS Manager Users.

   

2. Click Add User to add a user.

   

3. In the IIS Manager, right click the Sites folder in the Connections panel, and select Add Website.

   

4. Specify the site name, physical path, and binding information.

   

5. Expand the Sites folder. Select the newly created website first, and then double-click IIS Manager Permissions.

   

6. Click Allow User first, and then select IIS Manager in the dialog box. Click Select to select a user you added.

   

Adding Windows Users

To add Windows users

1. In the IIS Manager, right click on the Sites folder in the Connections panel, and then select Add Website.

   

2. Specify the site name, physical path, and binding information.

   

3. Expand the Sites folder. Select the newly created website first, and then double click IIS Manager Permissions.

   

4. Click Allow User. In the dialog box that appears, select Windows, and click Select.

   

5. Specify the object type, location, and enter the user name to select a user.

   

6. In the IIS Manager, select your site first, and then click Basic Settings.

   

7. Select Connect as > Specific user > Set to set the user name and password.

   

   

8. Click Test Settings in step 7 to test the connection.

   

Publishing a Project to IIS

To publish a project to IIS

1. In the Solution Explorer, right click on the project node, and select Publish.
2. In the window that appears, select the Web Deploy tab, and click Start.
3. Configure the publish profile, and click Next. Note that the user name can be either the IIS Web Deploy user name or the Windows user name.
4. Click Finish to continue.
5. Click Publish.

Troubleshooting

This topic describes the common errors that may occur when you publish projects to IIS.

• The site does not exist

This error would occur if you did not select the Complete setup type of Web Deploy to install. The Web deployment agent service will be not enabled for the other setup types of Web Deploy.

Solution:

Uninstall your current version of Web Deploy and then install the Complete version.

• The Web server is configured to not list the contents of this directory

  

Solution:

1. Launch the IIS Manager, select your site in the Connections panel, and click Directory Browsing.

2. Click Enable.

• Error concerning IIS application pool permission

When such error occurs, no data can be retrieved to your application and the error code 500 is returned. This is because the IIS application pool does not have permissions to log in to the database.

Solution 1:

Change the application pool identifier to a user who has access to the database.

Solution 2:

Change stdoutLogEnabled="false" to stdoutLogEnabled="true" in the web.config file that appears after the publish.

• Error indicating that files are locked when an application is published to a remote site where an application has previously been published

Solution 1:

Shut down and relaunch the site after the publish.

Solution 2:

Select the checkbox Remove additional files at destination when you configure the publish profile.

• Runtime error 500.30 when publishing .NET Core 2.2 application to IIS

Solution:

In the application configuration file, change "InProcess" to "OutOfProcess" in PropertyGroup, and add the ModelName property.

Error 502.5 might occur after you change the method. If this is the case, change the .NET path of Web API to an absolute path and restart your computer.

If Error 502.5 remains, you can check the event log. If the log indicates that the startup process fails, it might be caused by insufficient permissions. To fix the error, right click the website in the IIS Manager and select Advanced Settings. Choose Identity under Process Model, and select the Custom account to enter the local administrator's user name and password.

Publishing with Docker

This topic describes how to publish a project with Docker in SnapDevelop.

Docker Support in SnapDevelop

The support for Docker simplifies the development, test, and deployment of your containerized applications. SnapDevelop allows you to publish your projects to a registry on Docker Hub or MCR (Microsoft Container Registry), or to a self-hosted Docker registry.

There are two levels of Docker support you can add to a project:

• Docker support -- you can work with a container for a single project without using orchestration. For how to add Docker support, see Publishing a project to Docker.
• Docker Orchestrator support -- you can work with multiple services in containers using container orchestration with Docker Compose. For how to add Docker Orchestration support, see Adding Container Orchestrator support.

SnapDevelop includes a Docker Explorer where you can manage your Docker engines, images, and containers in a more efficient and productive way than using the raw Docker commands. For more information about the Docker Explorer, see Docker Explorer.

Docker Explorer

In SnapDevelop, you can open the Docker Explorer by selecting View > Docker Explorer. The Docker Explorer visualizes your images and containers in a tree view where you can perform various operations through the right-click menu.

Connecting to Docker engine

You can connect to a local or remote Docker engine in the Docker Explorer. To do that, click Connection to Docker Engine () in the Docker Explorer, and then specify the connection information (including the connection type, engine URL, and port number). To disconnect a Docker engine, right click on the connection, and select Close Connection.

Pulling images from registry

Once you are connected to a Docker engine, you can pull images from a registry on Docker Hub, MCR (Microsoft Container Registry), or from a self-hosted Docker registry.

To pull images from a registry, right click on the Docker engine, and select Pull from Registry. In the dialog box that appears, specify the registry and select the images to pull. You can view the progress in the Output window while pulling the images.

Managing images

After an image is loaded to the Docker Explorer, you can double click the image to show the basic information of the image in the window that opens. When you right click on an image in the Docker Explorer, the following options are available in the context menu:

• Run as a Container: Runs the image to start a container by configuring the container settings.
• New Tag: Creates a new tag for the image.
• Push: Pushes the image the registry.
• Delete: Deletes the image.

Managing containers

Containers are shown as sub nodes under the Containers node. For each container, the name of the image that the container was run from shows to the right of the container name. When you right click on a container in the Docker Explorer, the following options are available in the context menu:

• Start: Starts the container.
• Stop: Stops the container.
• Execute Command: Executes Linux commands in the container.
• Restart: Restarts the container.
• Delete: Deletes the container.

Prerequisites

Before working with Docker in SnapDevelop, you must have already set up your Docker environment. For more information about setting up the Docker environment, go to https://docs.docker.com/get-started/#set-up-your-docker-environment

Publishing a project to Docker

The procedure below shows you how to add Docker support to your project, publish and run an image as a container in SnapDevelop.

To publish a project with Docker

1. In the Solution Explorer, right click on the project node, and select Add > Docker Support.

2. In the Add Dockerfile dialog box, select the target OS for your application, and click OK. A file named Dockerfile is automatically created and added to the project in the Solution Explorer. The Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image. Docker can build images automatically by reading the instructions from a Dockerfile. SnapDevelop automatically generates a Dockerfile specific to your project when you add Docker Support, and you can customize the file to your needs if necessary. For more information about the Dockerfile, refer to the Dockerfile reference.

3. In the Solution Explorer, right click on the project node, and select Publish.

4. In the window that appears, select the Docker tab, and then click Start to configure the publish profile.

   Setting	Description
   Target	If you are connecting to your own repository (not part of an organization), leave the checkbox checked. If the repository is owned by an organization, clear the checkbox, and enter the organization name in the Organization field.
   Engine	Select a Docker engine, or select New Connection to connect to a new Docker engine.
   Registry	Select a Docker registry. You can select a registry on Docker Hub or MCR (Microsoft Container Registry), or select New Connection to connect to a self-hosted Docker registry.
   Organization	Specify your organization name. This field is visible only when the checkbox in the Target field is cleared.
   Image Name	Specify the image name.
   Tag	Specify a tag for the image.

5. Click Finish. If you publish to a registry on Docker Hub, a dialog box will appear asking for your Docker credentials to log in.

6. In the Docker Explorer, right click on the image and select Run as a Container.

7. In the window that appears, configure the container settings.

   Setting	Description
   Container Name	Specify the container name.
   Auto Remove on Stop	Automatically remove the container when it is stopped.
   Publish All Exposed Ports	Publish all the container’s exposed ports to the host. You can expose a port through the Dockerfile.
   Port Bindings	Specify the port mappings between your Docker host and the container.
   Volume Bindings	Specify the volume mappings between your Docker host and the container.
   Read-only	Mount the host directory as a read-only volume.
   Environment Variables	Set environment variables for the container.
   Restart Policy	Select a restart policy to control whether the container automatically restarts when it exits or stops.
   CMD	Define a default executable for the container, or provide default/additional arguments for the executable defined in the entrypoint instruction.
   Entrypoint	Define specific executable and arguments which cannot be overridden.

Adding Container Orchestrator support

SnapDevelop supports for container orchestrator enabling you to define and run multi-container Docker applications. You can only use container orchestration with Docker Compose at this version.

To add container orchestrator support to your solution

1. In the Solution Explorer, right click on each project node and select Add > Docker Orchestrator Support, and in the dialog box that appears, select the target OS.

   This adds a file named Dockerfile to each project, and adds a project named docker-compose to the solution.

   The Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image. Docker can build images automatically by reading the instructions from a Dockerfile. SnapDevelop automatically generates a Dockerfile specific to your each project when you add Docker Orchestrator Support, and you can customize the file to your needs if necessary. For more information about the Dockerfile, refer to the Dockerfile reference.

   The docker-compose project node includes the docker-compose.yml and .dockerignore files. The Compose file is a YAML file defining services, networks, and volumes. For more information about the Compose file, refer to the Compose file reference. The .dockerignore file helps to avoid unnecessarily sending large or sensitive files and directories to the daemon. For more information about the .dockerignore file, go to https://docs.docker.com/engine/reference/builder/#dockerignore-file. You can remove the Docker Orchestration Support by right clicking on the docker-compose project node and selecting Unload Project.

2. Click Run in the menu bar to start the service.

   After the service starts successfully, you see a new image added under the Images node in the Docker Explorer, and a new service node added under the Containers node with each container as sub node.

Publishing and Hosting an ASP.NET Core Application on Linux

In this topic, we create a Web API application, publish it using the File System method, and then host the app on Linux CentOS7 operating system following these steps:

• In SnapDevelop, publish the Web API application with middleware configured to support reverse proxy

• Copy over the Web API application from the local published folder to CentOS server

• In CentOS, host Web API application on CentOS with reverse proxy (Apache) configured

  For more information on how to set up Apache as a reverse proxy on CentOS 7, you can further read the Microsoft article: Host ASP.NET Core on Linux with Apache.

Prerequisites

• SnapDevelop 2019 R3
• Server running CentOS 7 with a standard sudo user account
• .NET Core Runtime is installed on CentOS 7 with the following instructions

Install .NET Core Runtime on CentOS 7

Before installing .NET Runtime, you need to register the Microsoft key, register the product repository, and install required dependencies. These only need to be done once per machine. Open a terminal and run the following commands:

# Install repository configuration
curl https://packages.microsoft.com/config/rhel/7/prod.repo > ./microsoft-prod.repo
sudo cp ./microsoft-prod.repo /etc/yum.repos.d/

# Install Microsoft's GPG public key
curl https://packages.microsoft.com/keys/microsoft.asc > ./microsoft.asc
sudo rpm --import ./microsoft.asc

Install the latest available updates for the product, then install the .NET Runtime.

In your terminal, run the following commands:

# Install the latest available updates for the product
sudo yum update

# Install the ASP.NET Core 3.1 runtime
sudo yum install aspnetcore-runtime-3.1

*The previous command will install the .NET Core Runtime Bundle, which includes the .NET Core runtime and the ASP.NET Core 3.1 runtime. To install just the .NET Core runtime, use the dotnet-runtime-3.1 package. Please note that, the runtime version must be the same as the version of the .NET Framework that you want your project to target.

Publishing an ASP.NET Core Application to Server

Preparation for the Application

In SnapDevelop, select File from the menu bar and then choose New > Project. In the dialog box, select C# > .NET Core and then select ASP.NET Core Web API. Then, fill in the project information to create a .NET Core project named WebAPI1 by clicking OK.

Some configurations for reverse proxy and Kestrel server need to be made before publishing.

Configuration for Forwarded Headers Middleware

Because requests are forwarded by reverse proxy, use the Forwarded Headers Middleware from the Microsoft.AspNetCore.HttpOverrides package. The middleware updates the Request.Scheme, using the X-Forwarded-Proto header, so that redirect URIs and other security policies work correctly.

Any component that depends on the scheme, such as authentication, link generation, redirects, and geolocation, must be placed after invoking the Forwarded Headers Middleware. As a general rule, Forwarded Headers Middleware should run before other middleware except for diagnostics and error handling middleware. This running order ensures that the middleware relying on forwarded headers information can consume the header values for processing.

Invoke the UseForwardedHeaders method in Startup.Configure before calling UseAuthentication or similar authentication scheme middleware. Configure the middleware to forward the X-Forwarded-For and X-Forwarded-Proto headers:

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

If no ForwardedHeadersOptions are specified to the middleware, the default forwarded headers are None.

Proxies running on loopback addresses (127.0.0.0/8, [::1]), including the standard localhost address (127.0.0.1), are trusted by default. For other trusted proxies or networks within the organization handling requests between the Internet and the web server, add them to the list of KnownProxies or KnownNetworks as options in ForwardedHeadersOptions. The following example adds a trusted proxy server at IP address 10.0.0.100 to the KnownProxies of Forwarded Headers Middleware in Startup.ConfigureServices:

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});

For more information, see Configure ASP.NET Core to work with proxy servers and load balancers.

Configuration for Secure (HTTPS) Local Connections

It is important for the application to make secure connections (HTTPS), configure the application to use a certificate for your development using one of the following approaches:

• Replace the default certificate from configuration (Recommended)
• KestrelServerOptions.ConfigureHttpsDefaults

The configuration for the application to listen to the URLs is in applicationUrl property in the Properties/launchSettings.json file, for example, https://localhost:5001;http://localhost:5000.

The app runs locally, so it is optional to configure the web server (Kestrel) with secure (HTTPS) local connections. You can remove https://localhost:5001 (if present) from the configuration.

Publishing the Application to a Local Folder

• In Solution Explorer, right-click the project and choose Publish.

• On the popup window, select File System.

• Specify the target location of publication.

• Go to Settings tab, change Target Runtime to linux-x64.

  Note that the application is configured for a framework-dependent deployment by default.

  

• Click Save to continue.

• Click Publish, then check the publication status in the Output window.

Copying the Application to the Server

Once the Web API application is published, copy the application from the published folder to the CentOS server using a tool that integrates into the organization's workflow (for example, SCP, SFTP). It's common to locate web applications under the var directory (for example, var/www/WebAPI1).

Hosting ASP.NET Core on CentOS with Apache

Configuring a Proxy Server

A reverse proxy is a common setup for serving dynamic web applications. The reverse proxy terminates the HTTP request and forwards it to the Web API application. In this example, Apache is configured as a reverse proxy, and Kestrel serves the Web API application. Apache forwards client requests to the Web API application running on Kestrel instead of fulfilling requests itself.

Installing Apache

Update CentOS packages to the latest stable versions:

sudo yum update -y

Install the Apache web server on CentOS with a single yum command:

sudo yum -y install httpd mod_ssl

To verify where Apache is installed, run whereis httpd from a command prompt.

Configuring Apache

Open the /etc/httpd/conf/httpd.conf file and set the ServerName directive globally:

sudo nano /etc/httpd/conf/httpd.conf

# Set ServerName in this configuration file
ServerName www.example.com:80

The configuration files for Apache are located in the /etc/httpd/conf.d/ directory. Any file with the .conf extension is processed in alphabetical order in addition to the module configuration files in /etc/httpd/conf.modules.d/, which contains all the necessary configuration files to load modules.

Create a configuration file:

sudo nano /etc/httpd/conf.d/WebAPI1.conf

An example of configuration files for the application:

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=$scheme
</VirtualHost>

<VirtualHost *:80>
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:5000/
    ProxyPassReverse / http://127.0.0.1:5000/
    ServerName www.example.com
    ServerAlias *.example.com
    ErrorLog /var/log/httpd/WebAPI1-error.log
    CustomLog /var/log/httpd/WebAPI1-access.log common
</VirtualHost>

The VirtualHost block can appear multiple times in one or more files on a server. In the preceding configuration file, Apache accepts public traffic on port 80. The domain www.example.com is being served, and the *.example.com alias resolves to the same domain. See Name-based virtual host support for more information. Requests are proxied at the root to port 5000 of the server at 127.0.0.1. For bi-directional communication, ProxyPass and ProxyPassReverse are required. To change Kestrel's IP/port, see Kestrel: Endpoint configuration

Warning: Failure to specify a proper ServerName directive in the VirtualHost block exposes your application to security vulnerabilities. Subdomain wildcard binding (for example, *.example.com) doesn't pose this security risk if you control the entire parent domain (as opposed to .com, which is vulnerable). See rfc7230 section-5.4 for more information.

Logging can be configured per VirtualHost using ErrorLog and CustomLog directives. ErrorLog is the location where the server logs errors, and CustomLog sets the filename and format of log file. In this case, this is where request information is logged. There's one line for each request.

Save the file and test the configuration. If everything passes, the response should be Syntax [OK].

sudo service httpd configtest

Restart Apache:

sudo systemctl restart httpd
sudo systemctl enable httpd

Monitoring the Application

Apache is now setup to forward requests made to http://localhost:80 to the Web API application running on Kestrel at http://127.0.0.1:5000. However, Apache isn't set up to manage the Kestrel process. Use systemd and create a service file to start and monitor the underlying web application. systemd is an init system that provides many powerful features for starting, stopping, and managing processes.

Creating the Service File

Create the service definition file:

sudo nano /etc/systemd/system/kestrel-webapi1.service

An example of service files for the application:

[Unit]
Description=Example .NET Web API application running on CentOS 7

[Service]
WorkingDirectory=/var/www/WebAPI1
ExecStart=/usr/share/dotnet /var/www/WebAPI1/WebAPI1.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=apache
Environment=ASPNETCORE_ENVIRONMENT=Production 

[Install]
WantedBy=multi-user.target

If the user apache isn't used by the configuration, the user must be created first and given proper ownership of the files.

Use TimeoutStopSec to configure the duration of time to wait for the application to shut down after it receives the initial interrupt signal. If the application doesn't shut down in this period, SIGKILL is issued to terminate the application. Provide the value as unitless seconds (for example, 150), a time span value (for example, 2min 30s), or infinity to disable the timeout. TimeoutStopSec defaults to the value of DefaultTimeoutStopSec in the manager configuration file (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). The default timeout for most distributions is 90 seconds.

# The default value is 90 seconds for most distributions.
TimeoutStopSec=90

Save the file and enable the service:

sudo systemctl enable kestrel-webapi1.service

Start the service and verify that it's running:

# Start the service
sudo systemctl start kestrel-webapi1.service

# Verify the service
sudo systemctl status kestrel-webapi1.service

● kestrel-webapi1.service - Example .NET Web API application running on CentOS 7
   Loaded: loaded (/etc/systemd/system/kestrel-webapi1.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2019-08-06 13:46:27 CST; 5s ago
 Main PID: 46668 (dotnet)
    Tasks: 16
   CGroup: /system.slice/kestrel-webapi1.service
           └─46668 /usr/share/dotnet/dotnet /var/www/WebAPI1/WebAPI1.dll

With the reverse proxy configured and Kestrel managed through systemd, the web application is fully configured and can be accessed from a browser on a local machine at http://localhost/api/sample/load. Inspecting the response headers, the Server header indicates that the Web API application is served by Kestrel:

HTTP/1.1 200 OK
Date: Tue, 06 Aug 2019 05:52:17 GMT
Server: Kestrel
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked

Viewing Logs

Since the web application using Kestrel is managed using systemd, events and processes are logged to a centralized journal. However, this journal includes all of the entries for services and processes managed by systemd. View the specific items of kestrel-webapi1.service with the following command:

sudo journalctl -fu kestrel-webapi1.service

For time filtering, specify time options with the command. For example, use --since today to filter for the current day or --until 1 hour ago to see the previous hour's entries. For more information, see man page for journalctl.

sudo journalctl -fu kestrel-webapi1.service --since "2019-08-06" --until "2019-08-06 23:00"

Configuring the Reverse Proxy for Secure (HTTPS) Client Connections

To configure Apache for HTTPS, the mod_ssl module is used. When the httpd module was installed, the mod_ssl module was also installed. If it wasn't installed, use yum to add it to the configuration.

sudo yum install mod_ssl

To enforce HTTPS, install the mod_rewrite module to enable URL rewriting:

sudo yum install mod_rewrite

Modify the /etc/httpd/conf.d/WebAPI1.conf file to enable URL rewriting and secure communication on port 443:

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=$scheme
</VirtualHost>

<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
</VirtualHost>

<VirtualHost *:443>
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:5000/
    ProxyPassReverse / http://127.0.0.1:5000/
    ErrorLog /var/log/httpd/WebAPI1-error.log
    CustomLog /var/log/httpd/WebAPI1-access.log common
    SSLEngine on
    SSLProtocol all -SSLv2
    SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:!RC4+RSA:+HIGH:+MEDIUM:!LOW:!RC4
    SSLCertificateFile /etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
</VirtualHost>

This example is using a locally-generated certificate. SSLCertificateFile should be the primary certificate file for the domain name. SSLCertificateKeyFile should be the key file generated when CSR is created. SSLCertificateChainFile should be the intermediate certificate file (if present) that was supplied by the certificate authority.

Save the file and test the configuration:

sudo service httpd configtest

Restart Apache:

sudo systemctl restart httpd

After HTTPS is fully configured, the web application can be accessed from a browser on a local machine at https://localhost/api/sample/load. Please pay attention here, it's https://....

Attribution

The content of this section incorporates some materials from “Host ASP.NET Core on Linux with Apache“ by Shayne Boyer licensed under CC BY 2.0.