If you're talking about the certificate errors under Admin > HTTPS, I wouldn't worry about those. An application does not need to validate its own certificate; it's only used to encrypt/decrypt the traffic.

The server transmits a copy of the certificate (without the private key), and the client validates the certificate before transmitting data.

Without getting into too many technical details, the only thing that really matters is if clients can connect to the application (ProGet) using HTTPS or not. There are a lot of reasons that may prevent the application from self-validation and it's not really worth trying to fix, since it's only used on that page to help catch basic errors.

Thanks,
Steve

thank you for your quick reply and the hint regarding registry.

However i couldn't identify potentially unsuitable registry settings within reasonable time, so instead i did a counter-check by importing the very same PFX file into Windows' certificate store.

I had to grant read permissions to "NETWORK SERVICE" for the imported private key, but this way the intermediate CA certificate is served to the clients properly.

Interestingly when switching back to the PFX file in ProGet's config afterwards (+ service restart), clients still receive the intermediate CA certificate. Only after deleting the intermediate CA certificate from Windows' certificate store, ProGet starts complaining about "Error PartialChain: A certificate chain could not be built to a trusted root authority." (root CA certificate is available in Windows' certificate store all the time).

This makes me think, that the current implementation doesn't read intermediate CA certificates from PFX files.

We're not aware of any bugs or issues; SSL and Certificate handling is all done at the Operating System (Windows) or Platform (.NET) level; we just point the system to the file. In my experience there's usually some obscure registry setting that will control stuff like this.

Thanks,
Steve