Squeak - Dev - SSL/Socket error code interpretation

SSL/Socket error code interpretation

Classic

List

Threaded

20 messages Options

timrowledge

SSL/Socket error code interpretation

I'm trying to make an https connection to a site and it isn't a happy thing.

After digging further into the SSL plugin than I ever wanted I found the logLevel setting and set it to 1 in SecureSocketStream>>#sslConnectTo: and got some plausibly useful info out of it.
The key item seems to be
sqConnectSSL: SSL_get_verify_result = 20
and if I've interpreted the code in ~opensmalltalk-vm/platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.inc and opensmalltalk-vm/platforms/Cross/plugins/SqueakSSL/SqueakSSL.h properly then an error code of 20 means SQSSL_INVALID_CN and SQSSL_CERT_EXPIRED.

Can anyone reassure me or correct me on that?

The problem is that according to the SSL code in *VW* the certificate I get has this info -
Validity
Not Before: Nov 15 00:00:00 2018 GMT
Not After: Nov 14 23:59:59 2020 GMT
Subject: OU=Domain Control Validated, OU=PositiveSSL, CN=sagetea.ai

... which looks in-date to me and a fairly reasonable CN.

Aaaargh!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: FR: Flip Record

Ron Teitelbaum

Re: SSL/Socket error code interpretation

Hi Tim,

This worked for me

WebClient new httpGet: 'https://sagetea.ai/'

and I checked it with this and it worked also:

| hostName address socket |
hostName := 'sagetea.ai'.
address := NetNameResolver addressForName: hostName.
socket := SecureSocket newTCP.
socket connectTo: address port: 443.
socket waitForConnectionFor: 10.
socket sslConnect.
socket certState = 0
ifFalse: [self error: 'woop woop wo woooo no good'].
(socket peerName match: hostName)
ifFalse: [self error: 'whoah nellie we connected to the wrong cert!'].
^ socket destroy

The connection looks fine. I'm using an older version of SqueakSSL. And I'm on windows.

I think the cert is fine.

All the best,

Ron

On Mon, May 11, 2020 at 9:48 PM tim Rowledge <[hidden email]> wrote:

I'm trying to make an https connection to a site and it isn't a happy thing.

After digging further into the SSL plugin than I ever wanted I found the logLevel setting and set it to 1 in SecureSocketStream>>#sslConnectTo: and got some plausibly useful info out of it.
The key item seems to be
sqConnectSSL: SSL_get_verify_result = 20
and if I've interpreted the code in ~opensmalltalk-vm/platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.inc and opensmalltalk-vm/platforms/Cross/plugins/SqueakSSL/SqueakSSL.h properly then an error code of 20 means SQSSL_INVALID_CN and SQSSL_CERT_EXPIRED.

Can anyone reassure me or correct me on that?

The problem is that according to the SSL code in *VW* the certificate I get has this info -
Validity
Not Before: Nov 15 00:00:00 2018 GMT
Not After: Nov 14 23:59:59 2020 GMT
Subject: OU=Domain Control Validated, OU=PositiveSSL, CN=sagetea.ai

... which looks in-date to me and a fairly reasonable CN.

Aaaargh!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: FR: Flip Record

Tobias Pape

Re: SSL/Socket error code interpretation

In reply to this post by timrowledge

Hi tim

> On 12.05.2020, at 03:48, tim Rowledge <[hidden email]> wrote:
>
> I'm trying to make an https connection to a site and it isn't a happy thing.
>
> After digging further into the SSL plugin than I ever wanted I found the logLevel setting and set it to 1 in SecureSocketStream>>#sslConnectTo: and got some plausibly useful info out of it.
> The key item seems to be
> sqConnectSSL: SSL_get_verify_result = 20
> and if I've interpreted the code in ~opensmalltalk-vm/platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.inc and opensmalltalk-vm/platforms/Cross/plugins/SqueakSSL/SqueakSSL.h properly then an error code of 20 means SQSSL_INVALID_CN and SQSSL_CERT_EXPIRED.
>
> Can anyone reassure me or correct me on that?

The 20 does not represent a SqueakSSL error code but an OpenSSL one:

20 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY: unable to get local issuer certificate
the issuer certificate could not be found: this occurs if the issuer certificate of an untrusted certificate cannot be found.

Which probably means that openssl does not find the COMODO issuer cert in its location.
Maybe we also did not set the path to the local cert store correctly...

When I use openssl s_client from macOS 10.12 OpenSSL (0.9.8), I get a similar result:

$ openssl s_client -connect sagetea.ai:443
CONNECTED(00000003)
depth=0 /OU=Domain Control Validated/OU=PositiveSSL/CN=sagetea.ai
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = sagetea.ai
verify error:num=21:unable to verify the first certificate
verify return:1
....

same for OpenSSL 1.1 and LibreSSL.

So, unless you have the Comodo intermediate Cert somewhere in a local cert store, 20 is correct.

Best regards
-Tobias

>
> The problem is that according to the SSL code in *VW* the certificate I get has this info -
> Validity
> Not Before: Nov 15 00:00:00 2018 GMT
> Not After: Nov 14 23:59:59 2020 GMT
> Subject: OU=Domain Control Validated, OU=PositiveSSL, CN=sagetea.ai
>
> ... which looks in-date to me and a fairly reasonable CN.
>
> Aaaargh!
>
> tim

Tobias Pape

Re: SSL/Socket error code interpretation

> On 12.05.2020, at 07:40, Tobias Pape <[hidden email]> wrote:
>
> Hi tim
>> On 12.05.2020, at 03:48, tim Rowledge <[hidden email]> wrote:
>>
>> I'm trying to make an https connection to a site and it isn't a happy thing.
>>
>> After digging further into the SSL plugin than I ever wanted I found the logLevel setting and set it to 1 in SecureSocketStream>>#sslConnectTo: and got some plausibly useful info out of it.
>> The key item seems to be
>> sqConnectSSL: SSL_get_verify_result = 20
>> and if I've interpreted the code in ~opensmalltalk-vm/platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.inc and opensmalltalk-vm/platforms/Cross/plugins/SqueakSSL/SqueakSSL.h properly then an error code of 20 means SQSSL_INVALID_CN and SQSSL_CERT_EXPIRED.
>>
>> Can anyone reassure me or correct me on that?
>
> The 20 does not represent a SqueakSSL error code but an OpenSSL one:
>
> 20 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY: unable to get local issuer certificate
> the issuer certificate could not be found: this occurs if the issuer certificate of an untrusted certificate cannot be found.
>
> Which probably means that openssl does not find the COMODO issuer cert in its location.
> Maybe we also did not set the path to the local cert store correctly...
>
> When I use openssl s_client from macOS 10.12 OpenSSL (0.9.8), I get a similar result:
>
> $ openssl s_client -connect sagetea.ai:443
> CONNECTED(00000003)
> depth=0 /OU=Domain Control Validated/OU=PositiveSSL/CN=sagetea.ai
> verify error:num=20:unable to get local issuer certificate
> verify return:1
> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = sagetea.ai
> verify error:num=21:unable to verify the first certificate
> verify return:1
> ....
>
> same for OpenSSL 1.1 and LibreSSL.
>
> So, unless you have the Comodo intermediate Cert somewhere in a local cert store, 20 is correct.

Aaand this is a common thing since >5 years:

https://stackoverflow.com/questions/25213923/ssl-site-and-browser-warning#25214924

-t

>
> Best regards
> -Tobias
>
>>
>> The problem is that according to the SSL code in *VW* the certificate I get has this info -
>> Validity
>> Not Before: Nov 15 00:00:00 2018 GMT
>> Not After: Nov 14 23:59:59 2020 GMT
>> Subject: OU=Domain Control Validated, OU=PositiveSSL, CN=sagetea.ai
>>
>> ... which looks in-date to me and a fairly reasonable CN.
>>
>> Aaaargh!
>>
>> tim
>
>
>

Tobias Pape

Re: SSL/Socket error code interpretation

>>> Can anyone reassure me or correct me on that?
>>
>> The 20 does not represent a SqueakSSL error code but an OpenSSL one:
>>
>> 20 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY: unable to get local issuer certificate
>> the issuer certificate could not be found: this occurs if the issuer certificate of an untrusted certificate cannot be found.
>>
>> Which probably means that openssl does not find the COMODO issuer cert in its location.
>> Maybe we also did not set the path to the local cert store correctly...
>>
>> When I use openssl s_client from macOS 10.12 OpenSSL (0.9.8), I get a similar result:
>>
>> $ openssl s_client -connect sagetea.ai:443
>> CONNECTED(00000003)
>> depth=0 /OU=Domain Control Validated/OU=PositiveSSL/CN=sagetea.ai
>> verify error:num=20:unable to get local issuer certificate
>> verify return:1
>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = sagetea.ai
>> verify error:num=21:unable to verify the first certificate
>> verify return:1
>> ....
>>
>> same for OpenSSL 1.1 and LibreSSL.
>>
>> So, unless you have the Comodo intermediate Cert somewhere in a local cert store, 20 is correct.
>
> Aaand this is a common thing since >5 years:
>
> https://stackoverflow.com/questions/25213923/ssl-site-and-browser-warning#25214924

And one More: curl on my Linux box does also no know about that cert:

% curl https://sagetea.ai
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
zsh: exit 60 curl https://sagetea.ai

(on mac, this works as it uses SecureTransport, if I'm not mistaken...)

Best regards
-Tobias

Squeak - Dev mailing list

Re: SSL/Socket error code interpretation

In reply to this post by timrowledge

Check your systems time.

My 32 bit machine loses date time on loss of power.

During squeak install preference wizard at step to optionally load git, osprocess, ffi, etc, the yes button is disabled with a warning message.

Set system date time with nntp calls and it works.

---- On Mon, 11 May 2020 21:48:37 -0400 [hidden email] wrote ----

I'm trying to make an https connection to a site and it isn't a happy thing.

After digging further into the SSL plugin than I ever wanted I found the logLevel setting and set it to 1 in SecureSocketStream>>#sslConnectTo: and got some plausibly useful info out of it.
The key item seems to be
sqConnectSSL: SSL_get_verify_result = 20
and if I've interpreted the code in ~opensmalltalk-vm/platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.inc and opensmalltalk-vm/platforms/Cross/plugins/SqueakSSL/SqueakSSL.h properly then an error code of 20 means SQSSL_INVALID_CN and SQSSL_CERT_EXPIRED.

Can anyone reassure me or correct me on that?

The problem is that according to the SSL code in *VW* the certificate I get has this info -
Validity
Not Before: Nov 15 00:00:00 2018 GMT
Not After: Nov 14 23:59:59 2020 GMT
Subject: OU=Domain Control Validated, OU=PositiveSSL, CN=sagetea.ai

... which looks in-date to me and a fairly reasonable CN.

Aaaargh!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: FR: Flip Record

Tobias Pape

Re: SSL/Socket error code interpretation

Hi Timothy,

> On 12.05.2020, at 13:30, gettimothy via Squeak-dev <[hidden email]> wrote:
>
> Check your systems time.
>
> My 32 bit machine loses date time on loss of power.
>
> During squeak install preference wizard at step to optionally load git, osprocess, ffi, etc, the yes button is disabled with a warning message.
>
> Set system date time with nntp calls and it works.

It's not a date issue. Its an issue with unavailability of intermetidate/root certs. The comodo ones are just not trusted by default on OpenSSL.

Best regards
-Tobias

>
>
> ---- On Mon, 11 May 2020 21:48:37 -0400 [hidden email] wrote ----
>
> I'm trying to make an https connection to a site and it isn't a happy thing.
>
> After digging further into the SSL plugin than I ever wanted I found the logLevel setting and set it to 1 in SecureSocketStream>>#sslConnectTo: and got some plausibly useful info out of it.
> The key item seems to be
> sqConnectSSL: SSL_get_verify_result = 20
> and if I've interpreted the code in ~opensmalltalk-vm/platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.inc and opensmalltalk-vm/platforms/Cross/plugins/SqueakSSL/SqueakSSL.h properly then an error code of 20 means SQSSL_INVALID_CN and SQSSL_CERT_EXPIRED.
>
> Can anyone reassure me or correct me on that?
>
> The problem is that according to the SSL code in *VW* the certificate I get has this info -
> Validity
> Not Before: Nov 15 00:00:00 2018 GMT
> Not After: Nov 14 23:59:59 2020 GMT
> Subject: OU=Domain Control Validated, OU=PositiveSSL, CN=sagetea.ai
>
> ... which looks in-date to me and a fairly reasonable CN.
>
> Aaaargh!
>
> tim

timrowledge

Re: SSL/Socket error code interpretation

In reply to this post by Squeak - Dev mailing list

> On 2020-05-12, at 4:30 AM, gettimothy via Squeak-dev <[hidden email]> wrote:
>
> Check your systems time.
>
> My 32 bit machine loses date time on loss of power.
>
> During squeak install preference wizard at step to optionally load git, osprocess, ffi, etc, the yes button is disabled with a warning message.
>
> Set system date time with nntp calls and it works.

An interesting but not-related issue - but do you not have your machine set to handle getting the time from ntp automagically? On my Pi's for example you have to do some moderately fiddly work to *prevent* that if you want to rely on an RTC HAT.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Computers are useless. They can only give you answers.

timrowledge

Re: SSL/Socket error code interpretation

In reply to this post by timrowledge

Thank you *very* much to Tobias and Levente for explaining this. At least it isn't just something I screwed up, so that makes me feel a bit less stupid. The connection has been working ok until recently though, which I suspect means somebody has been Fiddling With The Server. Hands may get slapped.

I thought I knew more about these certificate things than I ever wanted; now I know I know nothing. Which is *still* more than I ever wanted :-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Can easily be confused with facts.

Tobias Pape

Re: SSL/Socket error code interpretation

> On 12.05.2020, at 19:34, tim Rowledge <[hidden email]> wrote:
>
> Thank you *very* much to Tobias and Levente for explaining this. At least it isn't just something I screwed up, so that makes me feel a bit less stupid. The connection has been working ok until recently though, which I suspect means somebody has been Fiddling With The Server. Hands may get slapped.
>
> I thought I knew more about these certificate things than I ever wanted; now I know I know nothing. Which is *still* more than I ever wanted :-)

== If you control the server ==

Make sure to send a cert that includes the intermediate issuer, in this case
/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA

The cert chain via openssl s_client looks like this:

Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=sagetea.ai
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA

But should look like this:

Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=sagetea.ai
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority

(including the root cert "COMODO RSA Certification Authority" is _not_ recommended tho)

And then have the professionals check it:
https://www.ssllabs.com/ssltest/analyze.html?d=sagetea.ai&latest

Best regards
-Tobias

Levente Uzonyi

Re: SSL/Socket error code interpretation

On Tue, 12 May 2020, Tobias Pape wrote:

>
>> On 12.05.2020, at 19:34, tim Rowledge <[hidden email]> wrote:
>>
>> Thank you *very* much to Tobias and Levente for explaining this. At least it isn't just something I screwed up, so that makes me feel a bit less stupid. The connection has been working ok until recently though, which I suspect means somebody has been Fiddling With The Server. Hands may get slapped.
>>
>> I thought I knew more about these certificate things than I ever wanted; now I know I know nothing. Which is *still* more than I ever wanted :-)
>
> == If you control the server ==
>
> Make sure to send a cert that includes the intermediate issuer, in this case
> /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
>
> The cert chain via openssl s_client looks like this:
>
> Certificate chain
> 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=sagetea.ai
> i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
>
>
> But should look like this:
>
> Certificate chain
> 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=sagetea.ai
> i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
> 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
> i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
>
> (including the root cert "COMODO RSA Certification Authority" is _not_ recommended tho)
>
> And then have the professionals check it:
> https://www.ssllabs.com/ssltest/analyze.html?d=sagetea.ai&latest

hideResults?

Levente

>
>
> Best regards
> -Tobias

timrowledge

Re: SSL/Socket error code interpretation

In reply to this post by timrowledge

Follow up info just for the record - my sysadmin was able to correctly (re)install the certificate so we now get an 'A' report from ssllabs.com and the cURL etc checks all work. Thanks for the suggestions!

As an aside, Squeak 5.3-19435 running on the 20200429xxxxx ARMv6linux VM still fails the SSL test, but I think we established that the certificate included in the image for testing is a bit out of date?

> On 2020-05-12, at 10:34 AM, tim Rowledge <[hidden email]> wrote:
>
> Thank you *very* much to Tobias and Levente for explaining this. At least it isn't just something I screwed up, so that makes me feel a bit less stupid. The connection has been working ok until recently though, which I suspect means somebody has been Fiddling With The Server. Hands may get slapped.
>
> I thought I knew more about these certificate things than I ever wanted; now I know I know nothing. Which is *still* more than I ever wanted :-)
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- Can easily be confused with facts.
>
>
>
>

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
When all else fails, let a = 7. If that doesn't help, then read the manual.

Tobias Pape

Re: SSL/Socket error code interpretation

> On 19.05.2020, at 01:45, tim Rowledge <[hidden email]> wrote:
>
> Follow up info just for the record - my sysadmin was able to correctly (re)install the certificate so we now get an 'A' report from ssllabs.com and the cURL etc checks all work. Thanks for the suggestions!

Cool!

>
> As an aside, Squeak 5.3-19435 running on the 20200429xxxxx ARMv6linux VM still fails the SSL test, but I think we established that the certificate included in the image for testing is a bit out of date?
>
>

It is. But it already was when Andreas poured its contents into the image…
so it may be on purpose?

What's the remedy?
A long-term self-singed cert? This is only marginally better to test whether certificate checking works and no better to test whether TLS-encryption works :)

Best regards
-Tobias

>
>> On 2020-05-12, at 10:34 AM, tim Rowledge <[hidden email]> wrote:
>>
>> Thank you *very* much to Tobias and Levente for explaining this. At least it isn't just something I screwed up, so that makes me feel a bit less stupid. The connection has been working ok until recently though, which I suspect means somebody has been Fiddling With The Server. Hands may get slapped.
>>
>> I thought I knew more about these certificate things than I ever wanted; now I know I know nothing. Which is *still* more than I ever wanted :-)
>>
>> tim
>> --
>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>> Useful random insult:- Can easily be confused with facts.
>>
>>
>>
>>
>
>
> tim

timrowledge

Re: SSL/Socket error code interpretation

> On 2020-05-19, at 10:01 AM, Tobias Pape <[hidden email]> wrote:
>
>
>> On 19.05.2020, at 01:45, tim Rowledge <[hidden email]> wrote:
>>
>> As an aside, Squeak 5.3-19435 running on the 20200429xxxxx ARMv6linux VM still fails the SSL test, but I think we established that the certificate included in the image for testing is a bit out of date?
>>
>>
>
> It is. But it already was when Andreas poured its contents into the image…
> so it may be on purpose?
>
> What's the remedy?
> A long-term self-singed cert? This is only marginally better to test whether certificate checking works and no better to test whether TLS-encryption works :)

I'd imagine that we could do with several options; one that should work, one that should fail because of out of date, one with broken CN, etc. Might it be practical to set up a site from where we could download the example certificates when running the tests rather than cluttering up the normal image? Part of the test of course would be whether the examples could be downloaded :-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
To succeed in politics, it is often necessary to rise above your principles.

Tobias Pape

Re: SSL/Socket error code interpretation

> On 19.05.2020, at 19:05, tim Rowledge <[hidden email]> wrote:
>
>
>
>> On 2020-05-19, at 10:01 AM, Tobias Pape <[hidden email]> wrote:
>>
>>
>>> On 19.05.2020, at 01:45, tim Rowledge <[hidden email]> wrote:
>>>
>>> As an aside, Squeak 5.3-19435 running on the 20200429xxxxx ARMv6linux VM still fails the SSL test, but I think we established that the certificate included in the image for testing is a bit out of date?
>>>
>>>
>>
>> It is. But it already was when Andreas poured its contents into the image…
>> so it may be on purpose?
>>
>> What's the remedy?
>> A long-term self-singed cert? This is only marginally better to test whether certificate checking works and no better to test whether TLS-encryption works :)
>
> I'd imagine that we could do with several options; one that should work, one that should fail because of out of date, one with broken CN, etc. Might it be practical to set up a site from where we could download the example certificates when running the tests rather than cluttering up the normal image? Part of the test of course would be whether the examples could be downloaded :-)

In theory, yes, but this makes the test non-selfcontained and even more brittle on Travis (or whatever CI).
The problem is that it's not easy to have a properly signed Certificate[1], so we have to rely on a self-signed cert anyway.
Which means we already have to lower the certificate check criteria, so there is no point in having a non-expired one in the first place.
(For the default test)

We might probably need to test whether certain cert-checks work, but this actually only test Plugin-code no image code.
This is fine, but we have to be aware.

so may layers.

Best regards
-Tobias

[1]: Yes, there is Let's Encrypt and it is very good for actual use, but for tests not so much as we cannot really rely on their 3 month-expiry rule. It is really impractical to write meaningful tests in this setup, we would rather test whether Let's Encrypt works (which is pointless) than whether our stuff works.

timrowledge

Re: SSL/Socket error code interpretation

> On 2020-05-19, at 10:14 AM, Tobias Pape <[hidden email]> wrote:

> This is fine, but we have to be aware.
>
> so may layers.

I am very comfortable deferring tou your (or indeed anyone's) knowledge on this. I really don't want to even try to be expert here...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- If brains were taxed, he'd get a rebate.

Tobias Pape

Re: SSL/Socket error code interpretation

> On 19.05.2020, at 19:28, tim Rowledge <[hidden email]> wrote:
>
>
>
>> On 2020-05-19, at 10:14 AM, Tobias Pape <[hidden email]> wrote:
>
>> This is fine, but we have to be aware.
>>
>> so may layers.
>
> I am very comfortable deferring tou your (or indeed anyone's) knowledge on this. I really don't want to even try to be expert here...

I'm no expert either, rather someone "lobbed into cold water".
I don't even know how the SecureSocket works, I have never seen it work, only the SecureSocketStream
(or was it the other way round?).

Yes, there's room for improvement. But I'm not sure what extent of change would make a meaningful delta :)

Best regards
-Tobias

Squeak - Dev mailing list

Re: SSL/Socket error code interpretation

In reply to this post by Tobias Pape

Hi Tobias,

If the CI server could load the following config maps, you can access rootCerts in the SSLCertificateStore, when the CI server is running your tests.

NOTE: I would really like to see the Cryptography and ParrotTalk packages in the auto-testing regimen!

"Load Cryptography, Tests, ThunkStack, ParrotTalk. & SSL"
Installer ss
    project: 'Cryptography'; install: 'ProCrypto-1-1-1';
    project: 'Cryptography'; install: 'ProCryptoTests-1-1-1';
    project: 'Cryptography'; install: 'SSLLoader'.

"The loading of the SSL package is what loaded the SSLCertificateStore. Please explore the result and see roiot certificates."
SSLCertificateStore new.

There are a couple of certs read in, surely one of them would meet your needs.

Kindly,
Robert

On 5/19/20 1:01 PM, Tobias Pape wrote:

On 19.05.2020, at 01:45, tim Rowledge [hidden email] wrote:

Follow up info just for the record - my sysadmin was able to correctly (re)install the certificate so we now get an 'A' report from ssllabs.com and the cURL etc checks all work. Thanks for the suggestions!

Cool!

As an aside, Squeak 5.3-19435 running on the 20200429xxxxx ARMv6linux VM still fails the SSL test, but I think we established that the certificate included in the image for testing is a bit out of date?

It is. But it already was when Andreas poured its contents into the image…
so it may be on purpose?

What's the remedy?
A long-term self-singed cert? This is only marginally better to test whether certificate checking works and no better to test whether TLS-encryption works :)


Best regards
	-Tobias

On 2020-05-12, at 10:34 AM, tim Rowledge [hidden email] wrote:

Thank you *very* much to Tobias and Levente for explaining this. At least it isn't just something I screwed up, so that makes me feel a bit less stupid. The connection has been working ok until recently though, which I suspect means somebody has been Fiddling With The Server. Hands may get slapped.

I thought I knew more about these certificate things than I ever wanted; now I know I know nothing. Which is *still* more than I ever wanted :-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Can easily be confused with facts.

tim

-- 
Kindly,
Robert

Squeak - Dev mailing list

Re: SSL/Socket error code interpretation

Oh yes, the SSLCertificateStore has zero dependency on SSL and could be moved to ProCrypto

K, r

On 5/19/20 2:29 PM, Robert wrote:

Hi Tobias,

If the CI server could load the following config maps, you can access rootCerts in the SSLCertificateStore, when the CI server is running your tests.

NOTE: I would really like to see the Cryptography and ParrotTalk packages in the auto-testing regimen!

"Load Cryptography, Tests, ThunkStack, ParrotTalk. & SSL"
Installer ss
    project: 'Cryptography'; install: 'ProCrypto-1-1-1';
    project: 'Cryptography'; install: 'ProCryptoTests-1-1-1';
    project: 'Cryptography'; install: 'SSLLoader'.

"The loading of the SSL package is what loaded the SSLCertificateStore. Please explore the result and see roiot certificates."
SSLCertificateStore new.

There are a couple of certs read in, surely one of them would meet your needs.

Kindly,
Robert

On 5/19/20 1:01 PM, Tobias Pape wrote:
On 19.05.2020, at 01:45, tim Rowledge [hidden email] wrote:

Follow up info just for the record - my sysadmin was able to correctly (re)install the certificate so we now get an 'A' report from ssllabs.com and the cURL etc checks all work. Thanks for the suggestions!
Cool!
As an aside, Squeak 5.3-19435 running on the 20200429xxxxx ARMv6linux VM still fails the SSL test, but I think we established that the certificate included in the image for testing is a bit out of date?
It is. But it already was when Andreas poured its contents into the image…
so it may be on purpose?

What's the remedy?
A long-term self-singed cert? This is only marginally better to test whether certificate checking works and no better to test whether TLS-encryption works :)


Best regards
	-Tobias
On 2020-05-12, at 10:34 AM, tim Rowledge [hidden email] wrote:

Thank you *very* much to Tobias and Levente for explaining this. At least it isn't just something I screwed up, so that makes me feel a bit less stupid. The connection has been working ok until recently though, which I suspect means somebody has been Fiddling With The Server. Hands may get slapped.

I thought I knew more about these certificate things than I ever wanted; now I know I know nothing. Which is *still* more than I ever wanted :-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Can easily be confused with facts.
tim
-- 
Kindly,
Robert

-- 
Kindly,
Robert

Squeak - Dev mailing list

Re: SSL/Socket error code interpretation

Done so. SSLCertificateStore is now X509CertificateStore in the CryptographyX509 package.

DoIt to load latest:

"Load Cryptography, Tests, ThunkStack, ParrotTalk & SSL"
Installer ss
    project: 'Cryptography'; install: 'ProCrypto-1-1-1';
    project: 'Cryptography'; install: 'ProCryptoTests-1-1-1';
    project: 'Cryptography'; install: 'SSLLoader'.

DoIt: "Returns a map from subject name collection to Certificate."

| certMap |
certMap := Dictionary new.
X509CertificateStore new rootCerts
    do: [:e | certMap
        at: e tbsCertificate subject
        put: e].
^ certMap

K, r

On 5/19/20 2:32 PM, Robert wrote:

Oh yes, the SSLCertificateStore has zero dependency on SSL and could be moved to ProCrypto

K, r

On 5/19/20 2:29 PM, Robert wrote:
Hi Tobias,

If the CI server could load the following config maps, you can access rootCerts in the SSLCertificateStore, when the CI server is running your tests.

NOTE: I would really like to see the Cryptography and ParrotTalk packages in the auto-testing regimen!

"Load Cryptography, Tests, ThunkStack, ParrotTalk. & SSL"
Installer ss
    project: 'Cryptography'; install: 'ProCrypto-1-1-1';
    project: 'Cryptography'; install: 'ProCryptoTests-1-1-1';
    project: 'Cryptography'; install: 'SSLLoader'.

"The loading of the SSL package is what loaded the SSLCertificateStore. Please explore the result and see roiot certificates."
SSLCertificateStore new.

There are a couple of certs read in, surely one of them would meet your needs.

Kindly,
Robert

On 5/19/20 1:01 PM, Tobias Pape wrote:
On 19.05.2020, at 01:45, tim Rowledge [hidden email] wrote:

Follow up info just for the record - my sysadmin was able to correctly (re)install the certificate so we now get an 'A' report from ssllabs.com and the cURL etc checks all work. Thanks for the suggestions!
Cool!
As an aside, Squeak 5.3-19435 running on the 20200429xxxxx ARMv6linux VM still fails the SSL test, but I think we established that the certificate included in the image for testing is a bit out of date?
It is. But it already was when Andreas poured its contents into the image…
so it may be on purpose?

What's the remedy?
A long-term self-singed cert? This is only marginally better to test whether certificate checking works and no better to test whether TLS-encryption works :)


Best regards
	-Tobias
On 2020-05-12, at 10:34 AM, tim Rowledge [hidden email] wrote:

Thank you *very* much to Tobias and Levente for explaining this. At least it isn't just something I screwed up, so that makes me feel a bit less stupid. The connection has been working ok until recently though, which I suspect means somebody has been Fiddling With The Server. Hands may get slapped.

I thought I knew more about these certificate things than I ever wanted; now I know I know nothing. Which is *still* more than I ever wanted :-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Can easily be confused with facts.
tim
-- 
Kindly,
Robert
-- 
Kindly,
Robert

-- 
Kindly,
Robert