Warnings Displayed When Adding New TLS Certificate



  • I'm just getting started mucking around with TLS certificates.  I successfully created one for my FreeNAS box, and tried to do the same for my pfSense box.  However, when I add the CA or the TLS certificate, the following message appears in the Web GUI:

     Warning: openssl_x509_parse(): illegal ASN1 data type for timestamp in /etc/inc/certs.inc on line 394 Warning: openssl_x509_parse(): illegal ASN1 data type for timestamp in /etc/inc/certs.inc on line 394 Warning: openssl_x509_parse(): illegal ASN1 data type for timestamp in /etc/inc/certs.inc on line 444 Warning: openssl_x509_parse(): illegal ASN1 data type for timestamp in /etc/inc/certs.inc on line 444 Warning: openssl_x509_parse(): illegal ASN1 data type for timestamp in /etc/inc/certs.inc on line 480 Warning: openssl_x509_parse(): illegal ASN1 data type for timestamp in /etc/inc/certs.inc on line 480 Warning: openssl_x509_parse(): illegal ASN1 data type for timestamp in /etc/inc/certs.inc on line 490 Warning: openssl_x509_parse(): illegal ASN1 data type for timestamp in /etc/inc/certs.inc on line 490
    

    Also, the valid-from/to dates are not displayed in the new cert's list entry.  The contents of the cert display perfectly fine when copied to the pfSense system and fed to 'openssl x509 -text -in <certfile>', and the valid-until date is two years in the future (and not something crazy like the year 2099).  The same CA was accepted without incident on my Linux box and Firefox browser.

    The certificates were generated using GnuTLS's certtool v3.3.8.

    Can anyone suggest any hints?</certfile>



  • So.

    Near as I'm able to tell from a ridiculous amount of Google searching, dates in X.509 certificates can be represented in one of two ways: UTCTime, or GeneralizedTime.  UTCTime encodes a two-digit year (!??!??!), and ceases to make any sense after 2049.  GeneralizedTime has a four-digit year and has no such boneheaded limitation.  Further, near as I can tell, GnuTLS's certtool v3.3.8 only uses GeneralizedTime format when generating certificates.

    PHP, on the other hand, had a bug whereby openssl_x509_parse() only understood UTCTime-formatted dates, and which is the source of the warning messages.  This bug was fixed in May 2014 and, if the Git tag is to be believed, appears to have been released in PHP 5.6.5.

    I haven't been able to figure out which version of PHP is being used by pfSense 2.1.5, but hopefully this gets fixed in pfSense 2.2.

    What's rather less clear is whether these warnings are at all important, since the TLS negotiation is (obviously) not being done by PHP.  I've tried using the certificate for the Web GUI, anyway, but ended up being unable to re-connect to it (no errors or warnings; it just hangs).  I had to login to the console and repair the config by hand.  If anyone has any deeper insights into this stuff, I'd love to hear it.


  • Banned

    There certainly won't be PHP 5.6.5 in pfSense 2.2. Beyond that, GnuTLS is harmful for mental health.



  • @doktornotor:

    …GnuTLS is harmful for mental health.

    Really?  See, I wouldn't have thought so.  Granted, I've only been messing around with this for (checks watch) about ten hours total, but certtool seems far more direct and to-the-point compared with openssl, which seems to conjure an image of the proverbial kitchen sink, filled with rat's nests.

    Anyhoo, I'll try again using OpenSSL but, man, this is way way harder to get right than it needs to be.


  • Banned

    @ewhac:

    @doktornotor:

    …GnuTLS is harmful for mental health.

    Really?  See, I wouldn't have thought so.

    Yeah, really… Try using OpenLDAP on Debian with encryption and enjoy the galore of bugs stemming from OpenLDAP being compiled against the GnuTLS POS.

    Anyway, why are you doing this at all? There's a certificate manager that lets you create and manage certificates via the web GUI...



  • @doktornotor:

    Anyway, why are you doing this at all? There's a certificate manager that lets you create and manage certificates via the web GUI…

    Yes, I noticed – CA and certificate creation and management... running on the firewall... the box that is the first-line defense against network intrusion.  Maybe I'm missing something but, well-intentioned as the feature is, keeping and managing the cryptographic Crown Jewels from there seems kinda dumb.  I'd much rather cert management be done from an internal machine, and the necessary private keys kept offline entirely except when they're needed to sign something.



  • @ewhac:

    @doktornotor:

    Anyway, why are you doing this at all? There's a certificate manager that lets you create and manage certificates via the web GUI…

    Yes, I noticed – CA and certificate creation and management... running on the firewall... the box that is the first-line defense against network intrusion.  Maybe I'm missing something but, well-intentioned as the feature is, keeping and managing the cryptographic Crown Jewels from there seems kinda dumb.  I'd much rather cert management be done from an internal machine, and the necessary private keys kept offline entirely except when they're needed to sign something.

    so is the warning something to be concerned about?



  • @ewhac:

    Yes, I noticed – CA and certificate creation and management... running on the firewall... the box that is the first-line defense against network intrusion.  Maybe I'm missing something but, well-intentioned as the feature is, keeping and managing the cryptographic Crown Jewels from there seems kinda dumb.  I'd much rather cert management be done from an internal machine, and the necessary private keys kept offline entirely except when they're needed to sign something.

    Sure, keeping a CA that's completely off the network except for brief times when it's needed is best. Very few will actually go to that extent though. The firewall is generally the least-exposed of any system where most people would consider running something along those lines. Tell people "do it on another box" and they're probably going to do it on a web server that's open to the Internet running an 8 year old version of Joomla that gets owned on a daily basis. Is it the best-possible situation? Generally not. Is it the most secure option most people will practically consider? Yeah, in the majority of cases it is.



  • @donaldo:

    so is the warning something to be concerned about?

    It'll cause GUI display issues and the error pasted by OP because of the PHP bug linked earlier in this thread. Things that actually use the certs though should all be fine as none of that is dependent on PHP.


Log in to reply