Проблемы с запуском / настройкой консольного приложения (ASP.net core 2.1, Kestrel) с публичным сертификатом на веб-сервере Windows - PullRequest
Новая
       69

Проблемы с запуском / настройкой консольного приложения (ASP.net core 2.1, Kestrel) с публичным сертификатом на веб-сервере Windows

0 голосов
/ 22 ноября 2018

В прошлом я разрабатывал различные веб-сервисы (приложения VB ASP.net web-api) с использованием https для производства.Я сделал разработку с http и затем установил https на производственных серверах. Чтобы настроить порт на производственном сервере для https и сертификата, у меня есть:

  1. Импортированный публичный сертификат в хранилище сертификатов на сервере Windows настроил определенный порт для httpsс нетш.Например:

netsh http add urlacl url = https://+:22224/ пользователь = все

привязал сертификат (поверх отпечатка) к порту.Например:

netsh http add sslcert ipport = 0.0.0.0: 22224 certhash = 31cf73308a768100d4d32fe6e77638593e68ab57 appid = {a33a711f-c587-44e5-96bc} * 1013cf * dc8

Настройте приложение для прослушивания определенного порта, при этом я прочитал URL-адрес из файла конфигурации при запуске - например, https://IP:Port и применил его к (vb.net) HttpSelfHostConfiguration ()

Это работает без проблем, и я могу настроить приложения так, как мне нужно (например, настроить порт в файле конфигурации для http для выполнения тестов на сервере интрасети, настроить другой порт в файле конфигурации для производственной средыс https).

Теперь я хочу сделать то же самое с приложением asp.net core 2.1.6 и , похоже, оно работает не так.
Общий сертификат (comodo) установлен в хранилище сертификатов веб-сервера Windows.
Порт 22224 настроен с помощью netsh для https.
Сертификат связан с портом с помощью netsh (сертификат отображается правильно сnetsh http show sslcert ipport = 0.0.0.0: 22224
В Program.cs я добавляю порт для прослушивания с помощью UseUrls: 

 public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>() //;
            .UseUrls(GV.cURL, "http://localhost:5000"); 
    }

, посредством чего GV.curl содержит https://IP:22224 во время выполнения

Приложение работает нормально (через Интернет), если я настрою его на http -порт (например, http://IP:22222).
ЕслиЯ установил (настроенный) порт https (https://IP:22224), приложение не запускается и выдает сообщение об ошибке:
Невозможно настроить конечную точку HTTPS. Не указан сертификат сервера , и сертификат разработчика по умолчанию не найден.

Информация, которую я нашел в Интернете, сбивает с толку, и кажется, что эта тема «движущаяся цель »(часто изменяет базовую обработку ядра asp.net xx).
Мои выводы на данный момент:
Отрезано« Не указан сертификат сервера ”в сообщении об ошибке указывает, что сертификат должен быть настроен в приложении?

Я нашел пример для указания сертификатав CreateWebHostBuilder с параметрами .useKestrel: 

.UseKestrel(options =>
        {
            options.Listen(IPAddress.Loopback, 5000);
            options.Listen(IPAddress.Loopback, 5001, listenOptions =>
            {
                listenOptions.UseHttps("certificate.pfx", "topsecret");
            });

Примечание. В моем случае мне придется изменить 5001 на 22224.

Вопросы:

  • Нужно ли настраивать публичный сертификат (уже привязанный к порту) также в приложении asp.net core 2.1?

  • Если да, каков наилучший способ сделать это (пример вышехороший способ)?

Ответы [ 3 ]

0 голосов
/ 20 января 2019

Я использую Dockerized для моего ASP.Net Core App v2.2 и использовал следующие руководства для его работы (этот должен работать начиная с v2.1, январь 2017 г. ):

В основном я делал:

  • Сохраните сертификат (в данном примере для localhost development) в папке сертификатов: enter image description here
  • appsettings.json: 
    "Kestrel": {
      "applicationUrl": "https://localhost:5051;http://localhost:5050",
      "Certificates": {
        "Default": {
          "Path": "certificates/localhost.pfx",
          "Password": "MySecret",
          "AllowInvalid": "true"
        }
      }
    }
  • Установка URL-адресов приложений
    • с помощью launchsettings.json (только локальная разработка) 
    "kamapp-backend": {
      "commandName": "Project",
      "launchBrowser": true,
      "applicationUrl": "https://localhost:5051;http://localhost:5050",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }

  • через среду ASPNETCORE_URLS="http://+:5050;https://+:5051", например.ASPNETCORE_URLS="http://+:5050;https://+:5051" dotnet run

    • Вам не нужно кодировать какие-либо настройки, просто используйте файлы конфигурации.

Принудительное использование HTTPS: app.UseHsts(); inваш Startup.cs

Кажется, он также работает без "AllowInvalid": "true", но я пока не понимаю, почему.Может быть, кто-то может ответить.

0 голосов
/ 06 марта 2019

для среды разработки я использую приведенный ниже appsettings.json

Здесь я не использую https, я использовал http. 

{
  "Logging": {
    "LogLevel": {
      "Default": "Warning"
    }
  },
  "AllowedHosts": "*",
  "Kestrel": {
    "EndPoints": {
      "http": { "Url": "http://localhost:5000" }
    }
  }
}
0 голосов
/ 22 ноября 2018

После многих проб и ошибок я нашел соответствующую информацию, которая работает для меня.
Примечание: я работаю с ASP.net core 2.1.6 сейчас (если вы работаетев более старой версии это может не сработать ...

Вам не требуется для выполнения каких-либо настроек с помощью netsh, но вы должны настроить сертификат (включая пароль).
Кроме того, вам не нужно изменять program.cs ...
Конфигурации можно выполнить полностью в appsettings.json (входит в корневой каталог проекта)
Итак ... впроект (отладка на моем компьютере), я работаю с appsettings.json по умолчанию (с http): 

{
  "Logging": {
    "LogLevel": {
      "Default": "Warning"
    }
  },
  "AllowedHosts": "*"
}

На сервере intranet я использую другой appsettings.json (все ещес http): 

{
  "Logging": {
    "LogLevel": {
      "Default": "Warning"
    }
  },
  "AllowedHosts": "*"
,
    "Kestrel": {
      "EndPoints": {
        "Http1": { "Url": "http://localhost:5000" },
        "Http2": { "Url": "http://172.16.1.120:22222" }
        }
      }
    }

Таким образом, приложение может быть протестировано в локальной сети через IP-адрес сервера интрасети, а также непосредственно на сервере интрасети (порт localhost 5000).

На сервере internet я использую другой appsettings.json (для localhost сhttp, для IP-адреса сервера с https и сертификатом ): 

{
  "Logging": {
    "LogLevel": {
      "Default": "Warning"
    }
  },
  "AllowedHosts": "*"
,
    "Kestrel": {
        "EndPoints": {
            "Http": {
                "Url": "http://localhost:5000"
            },
            "HttpsInlineCertFile": {
                "Url": "https://192.168.3.3:22224",
                "Certificate": {
                    "Path": "./certificate.pfx",
                    "Password": "NotReally",
                    "AllowInvalid": "true"
                }
            }
        }
    }
}

Таким образом, приложение можно протестировать с помощью http непосредственно на сервере интрасети, а также с помощью https и сертификата через Интернет,

Обработка:

  • На серверах у меня есть корневой каталог приложения.
  • Прямо под рутом, я сохранил копии разных файлов "на машину" (включая appsettings.json)
  • Чтобы опубликовать новую версию, я публикую на своем компьютере разработчика и затем копируюкаталог \ publish \ на серверах (в корневом каталоге) и перезаписать сохраненные файлы.
  • Чтобы получить правильную конфигурацию, я создал простой .cmd , который копирует (специфичные для сервера) файлы конфигурации из корневого каталога в подкаталог \ publish \, который я запускаю после свежегоpublish ...

Примечания к https и сертификату:

  • Сертификат должен храниться в папке \ publish \.
  • Поскольку (мой) общедоступный сертификат contoso защищает несколько доменов, https работает правильно, только если приложение вызывается через домен (в противном случае показываются полезные «незащищенные» сообщения).
  • Чтобы протестировать приложение с помощью https, я открыл порт 22224 на Windows и «настоящий» брандмауэр.
  • DNS указывает на общедоступный IP-адрес нашего интернет-сервера.
    Для тестирования я вызываю приложение с https://www.Domain.xx:22224

И ... оно работает ...

...