Error importing from Artifactory: The SSL connection could not be established, see inner exception.

[michael.day_7391]

I have setup a docker feed, and am attempting to use the import images option. When I choose artifactory, and enter the url and credentials, and click "Select Feed" I get the following error:

The SSL connection could not be established, see inner exception.

I'm not sure what inner exception I'm supposed to be seeing.
I cannot find any logs in the Administration section under the diagnostic center or the additional logs and events sections related to this error. It does not get logged at all, other than in the popup window, and the stack trace that I've seen in other posts on this forum about the error is missing.

The certificate on the artifactory server is valid, and issued by LetsEncrypt, and is trusted by the operating system. I can open the artifactory url I'm using in the web browser on the Proget Windows Server 2019 server and I do not see any certificate errors.

[atripp]

Hi @michael-day_7391,

That's just a generic SSL error, which as you may know, is happening at the operating-system level. That quick-connect screen won't provide details. There may be a redirect happening, but it's hard to say.

It's unusual that it would work from the web browser, but also not uncommon. If you use Invoke-WebRequest that would reproduce the error. If not, then stop the service and run ProGet manually (proget.exe run) so it's the same user/account.

You should also be able to get a stack trace by adding a connector; that would be logged as a connector error.

Thanks,
Alana

[michael.day_7391]

@atripp said in Error importing from Artifactory: The SSL connection could not be established, see inner exception.:

Invoke-WebRequest

I was able to determine that the cause of the problem is that Windows, in an offline environment is unable to check certificate revocation, even when the root cert is added to the trusted root certification authorities store via GPO. Windows doesn't include LetsEncrypt certs in their trust by default.

Apparently, Chrome, RPM, docker, and Linux all automatically include LetsEncrypt certs, which is why the native docker clients, rpm clients, and chrome browser all connect without cert errors.

I have tried your suggestion, but It's not working. I've added a standard connector to the artifactory server, but I do not get any helpful errors in the log.

Unfortunately, the docker connector does not allow image browsing, so you have to type the image in the search path. It's not obvious what path I should check.

Connector: https://docker.artifactory.mydomain.com/

Artifactory lists file URL as https://docker.artifactory.mydomain.com/artifactory/docker-local/beats/filebeat/9.2.4/

I have tried the following searches which all fail:
artifactory/docker-local/beats/filebeat/9.2.4/
artifactory/docker-local/beats/filebeat:9.2.4
docker-local/beats/filebeat/9.2.4/
docker-local/beats/filebeat:9.2.4/
beats/filebeat/9.2.4/
beats/filebeat:9.2.4
filebeat/9.2.4/
filebeat:9.2.4

None of these searches log an errors in ProGet, so I still cannot tell why the SSL is failing...

Connector Note: Unfortunately, one or more connectors do not support third-party searching of their container registry, so you won't see any results from it, as you may expect. However, if you enter the exact repository name as the search term, it will display in the results.

No Images were found that matched "beats/filebeat:9.2.4".

[atripp]

Hi @michael-day_7391,

ProGet is not designed to provide many details on network- or OS-level errors; that's where tools like Invoke-WebRequest come in. And it sounds like you've already discovered the root cause (failed certificate revocation check) that way.

Anyway... when hosting ProGet on Windows, the Windows network stack will be used. So, if Windows is refusing to connect for whatever reason, then ProGet will also not connect. There's unfortunately no way around this, and we do not allow bypassing of SSL in ProGet.

The good news is, once you get Invoke-WebReuqest working, then you'll be able to connect. There's probably some magical registry setting out there that will help :)

Cheers,
Alana

[michael.day_7391]

I have solved the SSL issue by allowing firewall access to CRLs, however, now the import is failing because it can't find the artifactory local repository.

In artifactory, I have a local repo called "cozy-proxy" of type HelmOCI.

In Proget I have created a new feed of type Helm. I am connecting with the "Import packages from Artifactory" option, and using my full administrator credentials with username/password authentication.

When I get to the dropdown list that asks which artifactory local repository to import, the dropdown list is blank, and if I type "cozy-proxy" it doesn't find it.

[michael.day_7391]

So attempting imports from Artifactory here are the results:

1. Docker import : succeeded (using administrator username and password). It downloaded all the images into ProGet. Strangely enough, when I look at the Artifactory logs, it appears ProGet did not download as administrator, it downloaded as anonymous!
   "2026-02-03T17:16:39.409Z|42aa2e4a419b3fedad8559b05a1a241d|10.2.2.2|anonymous|GET|/api/docker/docker-local/v2/redis/blobs/sha256%3A95e910c2a21348907d21bb294dc886ab3160fd44dedfbc8aa872641185e6285e|200|-1|1002978|7|ProGet/25.0.19.14 (Microsoft Windows NT 10.0.17763.0)"

2. RPM Import: failed (using administrator username and password). Artifactory returns 403. Looking at artifactory log, it appears that ProGet is sending 'anonymous' instead of the credentials I gave it as evidenced by this artifactory log:
   "2026-02-03T17:24:55.659Z|e671ac4eeb05b7cb3a8b87684e1e2e15|10.2.2.2|anonymous|GET|/api/storage/node-exporter|403|-1|55|4|ProGet/25.0.19.14 (Microsoft Windows NT 10.0.17763.0)"

3. Helm Import: failed (using administrator username and password). The import screen did not show the helm repo in Artifactory. The list was empty, so import could not even be attempted.