Thank you very much for your precision. I realy appreciate it. I personaly work with non conterize Postgres database in order to avoid data corruption issue; but I understand your make this decision. Hava a good day, Mathieu HOFERT

Hello Mickael, ProGet does not support SSL on its own. However, if you have a reverse proxy like Traefik or nginx, you can terminate SSL in the reverse proxy and forward the connection to a locally-bound HTTP address. Here's the documentation for setting up SSL Traefik and nginx: https://docs.traefik.io/user-guide/examples/#http-https-with-sni https://nginx.org/en/docs/http/configuring_https_servers.html

The error is generic and there are many reasons why the SSL/TLS negotiation may fail. ServicePointManager.SecurityProtocol property selects the version of the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol to use for new connections; existing c# connections aren't changed. Make sure the ServicePointManager settings are made before the HttpWebRequest is created, else it will not work. Also, you have to enable other security protocol versions to resolve this issue: ServicePointManager.Expect100Continue = true; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 SecurityProtocolType.Tls SecurityProtocolType.Tls11 SecurityProtocolType.Ssl3; //createing HttpWebRequest after ServicePointManager settings HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/") If you create HttpWebRequest before the ServicePointManager settings it will fail and shows the error message.

Hello; Inedo.com currently seems to only communicate over TLS1.0; I don't have a timeframe for when that will be upgraded, but I want to add that we don't have any secure or sensitive information on inedo.com anyways. In the case of LDAP, it seems to me that there is some sort of issue with the LDAP code mapping your username. AD configuration can be very complicated I'm afraid, and it will involve a bit of back-and forth, with sharing potentially sensitive or company-identifying information. When you search for a user in ProGet, you will see a log of the domains, etc., being searched. Ifyou can publish that to a ticket, then we can investigate further.

That particular error message is a result of the connection string missing from the configuration file. Please ensure there is a key present in both web.config and in ProGet.Service.exe.config. Most likely, someone had inadvertantly deleted it from the configuration file when attempting to configure the server in IIS. <add key="InedoLib.DbConnectionString" value="Data Source=...;Initial Catalog=ProGet;Integrated Security=SSPI" />

Take a look at Changing an Inedo Product's URL with the Integrated Web Server; after setting up a certificate, you can follow this guide to register https urls, and edit the configuration file to listen on port 443 for ssl.

This isn't specific to ProGet at all, but HTTPS/SSL in general. It's not possible to bypass or address this from the server software (ProGet) side at all. You'll need to either trust the self-signed certificate on the client (Jenkins), install a certificate from a trusted root (server), or bypass that warning in the client (Jenkins).

Alright, well I did manage to make it work using IIS so at least there is a workaround, however since that was the only thing on that server that needed IIS it's too bad that I had to install and configure it only for that purpose. Thanks.

In Chocolatey v0.10.1, we will automatically switch to using better TLS versions when available. This was done in https://github.com/chocolatey/choco/issues/458. If you see this issue when you are attempting to install Chocolatey itself, please see this documentation to understand your options: https://github.com/chocolatey/choco/wiki/Installation#installing-with-restricted-tls

HTTPS/Certificates are at the socket layer... below ProGet's application layer. We're not familiar enough with Bower's internals, but it's most likely just using the operating system's network stack, and reporting warnings/errors from the underlying components. Likely it's a certificate trust issue between your computer and the ProGet server, or some intermediate authority. So, while there's nothing we can do on the PRoGet side, hopefully this helps point you in the right direction.