Skip to content
This repository has been archived by the owner on Feb 19, 2020. It is now read-only.

Regression from 1.3.1 #462

Open
viewers opened this issue Sep 7, 2017 · 5 comments
Open

Regression from 1.3.1 #462

viewers opened this issue Sep 7, 2017 · 5 comments

Comments

@viewers
Copy link

viewers commented Sep 7, 2017

It seems that the changes in xmlstream/cert.py are causing issues when connecting to google gcm servers.
(Not properly decoding the certificate date)

The old code works well -
if isinstance(not_before, GeneralizedTime):
not_before = datetime.strptime(not_before, '%Y%m%d%H%M%SZ')
else:
not_before = datetime.strptime(not_before, '%y%m%d%H%M%SZ')

if isinstance(not_after, GeneralizedTime):
    not_after = datetime.strptime(not_after, '%Y%m%d%H%M%SZ')
else:
    not_after = datetime.strptime(not_after, '%y%m%d%H%M%SZ')
@sijis
Copy link

sijis commented Sep 15, 2017

We got a report in errbotio/errbot#1101. I'm wondering if that is related to this.

A user suggested to revert to 1.3.1 from 1.3.3 and that seemed to have solve their problem.

@wrouesnel
Copy link

wrouesnel commented Oct 11, 2017

There is a general problem with how certificate date formats are being processed.

170705015212Z

Adding some extra logging lines:

16:14:03 DEBUG    sleekxmpp.xmlstream.xmlst Event triggered: ssl_cert
16:14:03 DEBUG    sleekxmpp.xmlstream.cert  Certificate Raw Not Before: 170705015212Z
16:14:03 DEBUG    sleekxmpp.xmlstream.cert  Certificate Not After: 1807-05-01 05:21:02
16:14:03 DEBUG    sleekxmpp.xmlstream.cert  Certificate Not Before: 1707-05-01 05:21:02
16:14:03 DEBUG    sleekxmpp.xmlstream.cert  Current Host Time: 2017-10-11 05:14:03.728545

It's parsing something but it's getting it really wrong, compared to openssl which gets it right:

openssl x509 -in cert.crt -enddate
notAfter=Jul  5 01:52:12 2018 GMT

EDIT: Rolling back to 1.3.1 fixed the problem for me as well.

@starstuck
Copy link

I have come across the same issue. I have discovered that pyasn1 library is already handling this problem. They seem to support 2 time variants GeneralizedTime and UTCTime. They seem to differ on number number of digits and few other things. I am not expert in certificates, but I would imagine that you can get times specified in one of those variants depending on certificate type or software used.

I have prepared a patch, that is using built in methods for those types for time conversion rather than serializing them and trying to parse them back. Please consider #472.

@Neustradamus
Copy link

1.3.2 works no?

@Neustradamus
Copy link

@viewers @sijis @wrouesnel @tomstarstuck: Have you tested with "master"?

It works?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants