OpenSSL problem after upgrade to 2.0-RELEASE

bill_mcgonigle

Hi, everybody,

I wonder if anyone has seen this:

    openssl library returns: error:0E06D06C:configuration file routines:NCONF_get_string:no value

when generating a certificate in the Certificate Manager. We had a working CA on 2.0-RC2 until the upgrade to 2.0-RELEASE.

I've verified that openssl.cnf is readable:

-rw-r--r--  1 root  wheel  8755 Sep 13 20:02 /etc/ssl/openssl.cnf

jimp

I haven't seen that, and I've done quite a lot of work with (and on) the certificate generation.

The file may be there, but does it contain sane data? You might try overwriting it with a good copy from the code repo on github.

bill_mcgonigle

Good thought - I did peruse it, but now I just pulled the latest from github, and ran a diff:

[2.0-RELEASE][admin@redacted.example.com]/etc/ssl(22): diff  openssl.cnf-old openssl.cnf
192c192                                                                                                                            
< nsComment                       = "OpenSSL Generated Certificate"                                                                
---                                                                                                                                
> nsComment                       = "OpenSSL Generated User Certificate"                                                           
214a215,225                                                                                                                        
> [ server ]                                                                                                                       
>                                                                                                                                  
> # Make a cert with nsCertType=server                                                                                             
> basicConstraints=CA:FALSE                                                                                                        
> nsCertType                    = server                                                                                           
> nsComment                     = "OpenSSL Generated Server Certificate"                                                           
> subjectKeyIdentifier=hash                                                                                                        
> authorityKeyIdentifier=keyid,issuer:always                                                                                       
> extendedKeyUsage=serverAuth                                                                                                      
> keyUsage = digitalSignature, keyEncipherment                                                                                     
>

but, unfortunately I get the same error. I wish I knew how to get it to tell me more verbosely which string it was trying to read, but I haven't managed to figure out a way to increase verboseness.

jimp

Looking at other hits on that error from other people, it seems to be something else on the system, not necessarily the openssl.cnf, that it doesn't have permission to read/write.

bill_mcgonigle

OK, tracked this down to a CA Certificate serial number format problem. Let me explain how I got there - I think we can prevent this for the next guy. The OpenSSL error seems to be a red herring, or at least too far down the chain to be useful.

I first looked over all the system for permissions problems, got a feeling for certs.inc, ran strings on the openssl library looking for filenames, tried to get DTrace working for open() (got 'DTrace device not available on system'?) but that was a dead end.

So, I figured since this was working on RC2 I'd look at the revision history on the files that were relevant (woo, github). I wound up at system_certmanager.php and saw that the error reporting/handling I was seeing had been added since then, and that warnings had been disabled:

$old_err_level = error_reporting(0); /* otherwise openssl_ functions throw warings directly to a
 page screwing menu tab */

I commented this out, and then when I tried again, I got:

Warning: openssl_csr_sign() expects parameter 6 to be long, string given in /etc/inc/certs.inc on line 283

Sure enough, it made the display ugly, but I was glad to see it. That line is:

        $res_crt = openssl_csr_sign($res_csr, $ca_res_crt, $ca_res_key, $lifetime,
                                 $args, $ca_serial);

And I found my CA serial was:

ea:50:5f:30:4e:c9:e2:6f

This serial comes from a cert which was imported from a CA run on a linux machine for pfSense 1.2.3.

Here's what's in the certificate:

[base64-decoded <ca><crt>] to ca.crt, then:

[2.0-RELEASE][admin@redacted.example.com]/root(33): openssl x509 -in ca.crt -noout -text                                
Certificate:                                                                                                                       
    Data:                                                                                                                          
        Version: 3 (0x2)                                                                                                           
        Serial Number:                                                                                                             
            ea:50:5f:30:4e:c9:e2:6f                                                                                                
...

So, I converted this to decimal (16884099664096911000) and now everything works. (yay, open source!)

Thoughts on ways to help:

understand this kind of serial number or
do input validation on entry and reject it.
capture openssl library warnings and add to the error output if an error is thrown.

Thanks for showing me that the problem was likely not in the config file!</crt></ca>

jimp

That serial number is not the same serial number referred to by that field.

The serial number of the certificate doesn't change, and is part of the encoded information.

The serial number field in the GUI is the number of the next certificate to be made from that CA. Certificates are revoked by their serial number, which for a child certificate of the CA is unique, and in the case of ours (and EasyRSA, and others) it's a decimal number.

An example CA:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            9c:3a:74:41:f1:df:7e:e5
[...]

And a client cert:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 19 (0x13)

And the certificate after that…

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 20 (0x14)

And so on.

bill_mcgonigle

Got it. Thank you for the explanation.

I filed bug 2031 with a suggestion for some expanded help text.

jimp

I committed the text fixes, should help clear things up. Thanks!