Documentation for enabling https does not work: eventId 1000

[michael.day_7391]

I have followed the directions here: https://docs.inedo.com/docs/installation/windows/web/https-support

When adding the https cert in ProGet web UI, it only gave me one command to run on the command line:

netsh http add urlacl url=https://*:443/ user="MYDOMAIN\PROGET-SERVER$"

I thought this was strange because the docs say to use NetworkService, not the machine account name for the netsh binding.

Then when I clicked OK, suddently I get ERR_CONNECTION_CLOSED in the web browser even after opening with the url https://PROGET-SERVER-URL

Windows event viewer shows event id 1000
Category: Microsoft.AspNetCore.Server.Kestrel EventId: 0 Overriding address(es) 'http://*:8624, https://*:443'. Binding to endpoints defined via IConfiguration and/or UseKestrel() instead.

I tried following the docs further and adding this command, but the server still does not start

netsh http add sslcert hostnameport=proget-hostname.mydomain.com:443 certhash=VALID_HASH certstorename=My appid="{VALID_GUID}"

When I attemp to keep following the documentation and bind NetworkService, it fails because the machine account bound through the command the web UI had me run has already bound:

netsh http add urlacl url=https://*:443/ user="NETWORK SERVICE"

Url reservation add failed, Error: 183
Cannot create a file when that file already exists.

Here is the relevant data that was added to proget.config

<WebServer Enabled="true" Urls="http://*:8624;https://*:443" Subject="proget-url.mydomain.com" Store="My" Location="LocalMachine" AllowInvalid="True" UseHttpsRedirection="True" />

[rhessinger]

Hi @michael-day_7391,

The docs say to use NETWORK SERVICE because that is the default account ProGet users when it's installed. You need to use the username of the account that the ProGet service is running as. If your ProGet service is running as MYDOMAIN\PROGET-SERVER$", then your netsh command should use that. If it is using NETWORK SERVICE, then you should be use NETWORK SERVICE. If you want to switch to a different username, then you need to first remove the urlacl by running the following, then re-add it with the correct name.

netsh http delete urlacl url==https://*:443/

The event viewer error Windows event viewer shows event id 1000, can be ignored. That is a default message that shows because we configure the URL binding in code.

The netsh http add sslcert command should only be used when you are using a haostname binding, since you are unsign *:443, you should not need this.

While you are working through this issue, I would change UseHttpsRedirection="True" to UseHttpsRedirection="False" in your config so you can still access the site over HTTP until you get this figured out. The ERR_CONNECTION_CLOSED message typically indicates an issue with the certificate binding. The most common issue that can cause this is when the permissions are incorrect on your certificate.

1. Open the Certificate Manager using Window's MMC
2. Navigate to Certificates (Local Computer) -> YOUR_STORE (ex: Personal) -> Certificates
3. Right click on the certificate and select All Tasks -> Manage Private Keys
4. And give read access to your service account

See more in our Troubleshooting guide.

Can you verify the permissions on the certificate?

Thanks,
Rich

[michael.day_7391]

Thanks, re-adding the acl with the user set to NETWORKSERVICE worked.

Maybe it's just me, but if the web UI knows the server is running as NETWORKSERVICE, shouldn't the command it gives you in the web UI at the end of the setup process use the NETWORKSERVICE, and not give you the incorrect command using the computer account name?

I did assume that the instructions it gave me were valid, and that assumption turned out to be false.

[rhessinger]

Hi @michael-day_7391,

What version of Windows Server are you running?

When generating that command, ProGet will call Environment.UserName to determine the username the service is running as. I'm guessing this is returning the computer account instead of NETWORK SERVICE. I have crated a ticket, PG-3219, to review it, but I would like to test it on the same version of Windows Server as you.

Thanks,
Rich