Syrinscape Creator Login Issues - FIXED?


Hi there,

I’m having the same login issues as detailed in this thread and this thread. I’ve taken some steps to debug the problem myself which I hope are helpful as it seems others have also encountered this behaviour. The rest of this post is technical mumbo-jumbo.

My username and password are definitely correct. They are provided by the same password manager I use to log in at and I have compared the values explicitly.

The error I receive is “From callback, Error getting response stream (Write: The authentication or decryption has failed.): SendFailure”. The content of that error with “From callback” removed is an error others have encountered verbatim in C#/Mono contexts and in Unity projects:

If I use Wireshark to watch traffic, I see the start of a TLSv1 handshake between my client (presumably the Creator server) and in which my client rejects the handshake because the certificate is invalid. It receives a certificate in which subject=/CN=* and issuer=/CN=* instead of the legitimate certificate.

I observe this same behaviour if I connect to the server directly using openssl without an SNI extension:
openssl s_client -connect -tls1_2

The certificate is providing under these conditions is the same one found by default for some letsencrypt configs as located here:

I observe the correct behaviour if I add an SNI extension in OpenSSL, as in:
openssl s_client -connect -tls1_2 -servername

Looking back at the packet capture for the original exchange, the one triggered by the Syrinscape Creator software, I can see that Syrinscape (or its underlying HTTP framework) didn’t send an SNI extension in its ‘Client Hello’ TLS handshake. The OpenSSL behaviour suggests that the site totally fails to work without an SNI extension. This can be confirmed using the standard SSLLabs toolset and opening the panel labelled Certificate #2: RSA 2048 bits (SHA1withRSA) No SNI:

It’s strange, then, that the application typically works for everyone and has only broken down in these isolated cases. Figuring out exactly why this occuring requires more information about the context these requests are being sent from, but hopefully that’s a good starting point.


I just started having this error myself a couple hours ago.


Oh dear. It will be good to see if anyone else is suddenly seeing this. If so, I would suspect that either the devs have made server-side changes and know what they were, or AWS has started behaving differently when SNI extensions are not provided.


Yup. Looks like it’s become broken! :disappointed:

Dev team looking at it right now.

Thanks for the heads up! :slight_smile:


OK. Looks like things should be working again.

Everybody check?



Seems to be behaving itself now!




Dev team says:
“Sorry everybody. We had run some system updates earlier, and one of them appears to have restored a default setting that needed to be unset.”