Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

SSL not working with sub-subdomains longer than SSL_MAX_SSL_SESSION_ID_LENGTH #975

Closed
jgdye opened this Issue Jun 4, 2013 · 7 comments

Comments

Projects
None yet
4 participants

jgdye commented Jun 4, 2013

Using both the compiled stable nightly and the Ubuntu PPA version on server x64, as well as compiled stable nightly on Raspbian, when I try to add SSL to a sub-subdomain (e.g. x.y.z.com), I get the following error:

04/06/2013 15:43:38.021 cryptor_libssl.c:506 - Unable to set SSL
session-id context for 'x.y.z.com':
error:140DB111:SSL routines:SSL_CTX_set_session_id_context:ssl session id
context too long | The issue seems to be related to your system.

When I remove one of the levels of sub-domain, it works as expected. I've chained the certificate files, and the same certificate file works on Apache, postfix, and dovecot. I also chained a certificate for y.z.com using the same method, and cherokee worked without error.

@skinkie skinkie was assigned Jun 4, 2013

Member

skinkie commented Jun 4, 2013

I'll take a peak later to see if I can reproduce it locally. If anyone already knows what the issue is feel free to jump in.

http://www.openssl.org/docs/ssl/SSL_CTX_set_session_id_context.html

I wonder what SSL_MAX_SSL_SESSION_ID_LENGTH and how far we are overshooting this value. If you feel lucky and want to get your hands dirty you could figure that length out. Or shorten the virtual server name in the configuration not to represent the domainname but match it with wildcards only.

/* Set the SSL context cache
 */
rc = SSL_CTX_set_session_id_context (n->context,
                     (unsigned char *) vsrv->name.buf,
                     (unsigned int)    vsrv->name.len);

jgdye commented Jun 5, 2013

The particular issues mentioned there seem to be different. Experimenting on the Raspbian install (the only one I had access to tonight, I noted that the cutoff is 24 characters for the name on that system. A 24 character name works, a 25 character one does not. It just happened that all my sub-subdomains happen to be 25+ characters. Using a shorter name and even the full FQDN for regex or wildcard matching work as expected. Now that I know this, I can solve my problem easily, but it would be nice to at least have a note about it in the documentation.

EDIT: To clarify, the second link may be related, but the referenced patch appears to already have been applied by v1.2.103

Member

skinkie commented Jun 10, 2013

I'm considering:

  • hashing the virtual server name (MD5/SHA1/CRC32)
  • storing up to the nth character with MIN(SSL_MAX_SSL_SESSION_ID_LENGTH, vsrv->len)
  • storing the pointer of the vserver object (or list member property) to uniquely reference it

@skinkie skinkie closed this in f29a690 Jul 27, 2013

arideden commented Jul 4, 2015

I'm posting here because this thread has a lot of google-juice.
I'm still getting this error with Cherokee 1.2.103. It turned out to be the length of the nick used to identify the vserver I was configuring with SSL. Through trial and error I have determined a 32 character maximum nick length to configure SSL on a vserver.
The solution (if your overly long domain choice is made for you) is to use some small string for the vserver's nick, and change the vserver's host match from nick, to regexp. Enter in your domain, preceding special characters (eg .) by .

Member

skinkie commented Jul 4, 2015

Could you at least confirm that the github version works for you?

arideden commented Jul 4, 2015

Apologies skinkie, I recognise this is a developer forum, but the comment was intended for dumb sysadmins googling for the error message. The server I'm working on is a production CentOS 6 server with the Cherokee package installed from EPEL. I didn't consider testing a dev version on a production system.
(Although now that I've spent some time to compare the release date of 1.2.103 with the date this thread was started, I realise the problem is likely fixed in the current github version).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment