SSL error when using Docker image

I’m trying to create a new release for a project using the latest docker image found at https://hub.docker.com/r/octopusdeploy/octo/

I run the following command:
docker run --rm octopusdeploy/octo create-release --Project project --deployto env --server=https://server --ignoreSslErrors --apikey API-MYAPIKEY --progress

But I get the follwing error:
Octopus Deploy Command Line Tool, version 4.42.6

The following certificate errors were encountered when establishing the HTTPS connection to the server: RemoteCertificateChainErrors
Certificate subject name: CN=certname

Error repeates itself over and over. So even though I use the --ignoreSslErrors flag it still gives me this error.

Also. If I run the same command with but with the .NET core version of it works just fine. I don’t even have to specify the –ignoreSslErrors flag

Hi Tobias

Thanks for reporting this. I’m going to set up a repro environment to see if I can replicate - I note that you’ve got a workround using the .NET core version - does that get you up an running at this point, or do you need a resolution to this specific isue?

If you’re OK with the workround, then I’d be inclined to set up a repro and move this problem to a Github Issue, rather than this help site. Let me know either way

Thanks

Jason

Hi Jason. I understand this can be a quite delicate problem to solve.
Unfortunately, using the .NET core version isn’t really going to work since this was going to be a part of a GitLab pipeline which builds on linux images. So it doesn’t really help me here.

Thanks
Tobias

OK, understood. Let’s see if we can expedite this as a support ticket then, and I’ll roll on with my repro. I currently suspect we might have a compiler flag set around this code block that’s maybe not quite configured right, but I’ll need a little support form the dev team. I’ll keep you posted as to what we find

Jason

HI Tobias,

I’m in the code at the moment, and the code path I can see suggests we only send out the text “The following certificate errors” as a warning, not as a terminating error. Can I confirm :

Does your test scenario still create the release as requested?
Does the warning stop subsequent commands from running?

thanks

Jason

Sorry, but no. It doesn’t create any release. But now I actually let it run for a long time and then I got an Exception with call stack. So that might come in handy.

System.Exception: Unable to connect to the Octopus Deploy server. See the inner exception for details. —> System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, ExceptionDispatchInfo exception)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.PartialFrameCallback(AsyncProtocolRequest asyncRequest)
— End of stack trace from previous location where exception was thrown —
at System.Net.Security.SslState.ThrowIfExceptional()
at System.Net.Security.SslState.InternalEndProcessAuthentication(LazyAsyncResult lazyResult)
at System.Net.Security.SslState.EndProcessAuthentication(IAsyncResult result)
at System.Net.Security.SslStream.EndAuthenticateAsClient(IAsyncResult asyncResult)
at System.Net.Security.SslStream.<>c.b__47_1(IAsyncResult iar)
at System.Threading.Tasks.TaskFactory1.FromAsyncCoreLogic(IAsyncResult iar, Func2 endFunction, Action1 endAction, Task1 promise, Boolean requiresSynchronization)
— End of stack trace from previous location where exception was thrown —
at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken)
— End of inner exception stack trace —
at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken)
at System.Threading.Tasks.ValueTask1.get_Result() at System.Net.Http.HttpConnectionPool.CreateConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken) at System.Threading.Tasks.ValueTask1.get_Result()
at System.Net.Http.HttpConnectionPool.WaitForCreatedConnectionAsync(ValueTask1 creationTask) at System.Threading.Tasks.ValueTask1.get_Result()
at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
at System.Net.Http.AuthenticationHelper.SendWithAuthAsync(HttpRequestMessage request, Uri authUri, ICredentials credentials, Boolean preAuthenticate, Boolean isProxyAuth, Boolean doRequestAuth, HttpConnectionPool pool, CancellationToken cancellationToken)
at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
at Octopus.Client.OctopusAsyncClient.DispatchRequest[TResponseResource](OctopusRequest request, Boolean readResponse) in D:\buildAgent\workDir\d8818cc5a2905d1\source\Octopus.Client\OctopusAsyncClient.cs:line 553
at Octopus.Client.OctopusAsyncClient.Get[TResource](String path, Object pathParameters)
at Octopus.Client.OctopusAsyncClient.EstablishSession() in D:\buildAgent\workDir\d8818cc5a2905d1\source\Octopus.Client\OctopusAsyncClient.cs:line 481
— End of inner exception stack trace —
at Octopus.Client.OctopusAsyncClient.EstablishSession() in D:\buildAgent\workDir\d8818cc5a2905d1\source\Octopus.Client\OctopusAsyncClient.cs:line 494
at Octopus.Client.OctopusAsyncClient.Create(OctopusServerEndpoint serverEndpoint, OctopusClientOptions options, Boolean addHandler) in D:\buildAgent\workDir\d8818cc5a2905d1\source\Octopus.Client\OctopusAsyncClient.cs:line 134
at Octopus.Client.OctopusAsyncClient.Create(OctopusServerEndpoint serverEndpoint, OctopusClientOptions options) in D:\buildAgent\workDir\d8818cc5a2905d1\source\Octopus.Client\OctopusAsyncClient.cs:line 116
at Octopus.Cli.Commands.ApiCommand.Execute(String[] commandLineArguments) in D:\buildAgent\workDir\d8818cc5a2905d1\source\Octopus.Cli\Commands\ApiCommand.cs:line 140
at Octopus.Cli.CliProgram.Run(String[] args) in D:\buildAgent\workDir\d8818cc5a2905d1\source\Octopus.Cli\CliProgram.cs:line 52
Exit code: -3

Hey Tobias,

Just wanted to give you a quick update on this - we do have an open issue around --ignoreSslErrors which was opened around Mac support, that should be merging shortly. I had a chat with the colleague who’s shepherding that fix through, and he suspects it might help.

WRT using the docker image in place of just pulling down the appropriate .NET Core/portable binary - is that a gitlab thing? I’m not particularly familiar with how gitlab works so forgive what might be a bit of a silly question.

Jason

Thanks Jason.
Thats good, please let me know when it’s merged so I can try it out.

You are correct. I could use that kind of setup for a Docker image and pull everything down etc. But in the long run it would be the best for me to just pull the latest you have build to make sure that everything is up to date.
So, I have considered that already as an alternative option.

//Tobias

Hi Tobias, quick update:

I’ve got a working repro up and running. The latest Alpine image definitely fails repeatedly when running against a server with a self-signed cert configured, then exits with status -3. When the cert is valid (either a “proper” valid cert or supplied by LetsEncrypt), it works beautifully, naturally.

I’m consulting with the dev dealing with the in-progress PR I noted previously, and I’ll keep you posted, but I’m not sure it’s exactly the same behaviour.

Jason

Oh, one thing I forgot: I assume there’s a particular reason this Octopus instance is set up with a self-signed/mismatched cert? We do get a lot of people using internal DNS names, which is totally valid. Just intrigued as to the setup.

Jason

After some investigation I’ve opened an issue over on github - there’s some suspicion that SSL error policies aren’t fully implemented in .NET Core, so we’re going down a code path that the runtime can’t handle elegantly. Merits further investigation for sure.

Hi Jason. Thanks for the update!

Regarding the certification signing process. That is the path the IT operations team has choosen to take, but I’ll bring it up with them as a possible problem and possibly buy a root cert that has another issuer.
FYI, my expertice within certificates are limited unfortunately.