ca.crt verification error with openssl 1.1.0 (illegal zero content in Field=serialNumber)

This forum was archived to /woltlab and is now in read-only mode.
  • Hello Community,

    wWith Debian 9 the openssl version was brought to Verison 1.1.0f. It looks like this version does not accept certificates with a serial number starting witrh a 0 anymore. But my ca.crt has as Serialnumber "0" so Icinga throws:

    1. [2017-08-23 09:51:05 +0200] critical/SSL: Error loading and verifying locations in ca key file '/etc/icinga2/pki/ca.crt': 219029726, "error:0D0E20DE:asn1 encoding routines:c2i_ibuf:illegal zero content"
    2. [2017-08-23 09:51:05 +0200] critical/config: Error: Cannot make SSL context for cert path: '/etc/icinga2/pki/someIcingaHost.crt' key path: '/etc/icinga2/pki/someIcingaHost.key' ca path: '/etc/icinga2/pki/ca.crt'.

    "openssl x509 -in /etc/icinga2/pki/ca.crt -text -noout" gives the following output on openssl 1.1.0f

    1. openssl x509 -in /etc/icinga2/pki/ca.crt -text -noout
    2. unable to load certificate
    3. 140707291538688:error:0D0E20DE:asn1 encoding routines:c2i_ibuf:illegal zero content:../crypto/asn1/a_int.c:154:
    4. 140707291538688:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:609:Field=serialNumber, Type=X509_CINF
    5. 140707291538688:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:../crypto/asn1/tasn_dec.c:609:Field=cert_info, Type=X509
    6. 140707291538688:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:../crypto/pem/pem_oth.c:33:

    On openssl 1.0.1 (Jessie f.e. ) all works fine and i can see that the ca.crt has "0" as serialnumber.

    So my Question is:

    Is there an easy way to create a new root zertificate and still accepting the old one until the migration to the new one is complete ?

    Thanks for help!

  • Can you extract the ca.crt's creation/issue date? Does this happen with a freshly created ca.crt on a test host too, or only with old CA certificates?

  • Can you extract the ca.crt's creation/issue date? Does this happen with a freshly created ca.crt on a test host too, or only with old CA certificates?

    if i create a new ca on master with old openssl 1.0.1 i will get a working certificate:

    Its possible to create a new certificate based on the old key with icinga ?

    The post was edited 1 time, last by unic ().

  • As the problem is only with serial numbers starting with a "0" the certificates the Client certificates should not have any problems. As example i have found an old (working) certificate from 2016:

    1. Certificate:
    2. Data:
    3. Version: 3 (0x2)
    4. Serial Number: 107 (0x6b)
    5. Signature Algorithm: sha256WithRSAEncryption
    6. Issuer: CN=Icinga CA
    7. Validity
    8. Not Before: Mar 2 12:09:11 2016 GMT
    9. Not After : Feb 27 12:09:11 2031 GMT

    Here is some more info about the problem with the leading "0" in 1.1.0.f:


    So i think, that everyone how has used Debian Jessie with icinga in a specific time frame may have this problem. As far a i know its no longer possible to create certificates starting with a 0 with newer openssl versions.

  • I've read that article too some days ago, thanks.

    It is unfortunate that older CA certificates contained the leading zero. This was fixed a while back, but the underlaying error was not shown, as OpenSSL 1.0.x ignored the error. I did not know that 1.1.0 was released as stable (I only remember the pre 1.1.0 last year), so it might break more things than just the certificate.

    This is tracked here, although the only working solution will be regenerated certificates.

    If your client certificates are not affected, you can re-create a public CA certificate from the existing key pair (ca.crt and ca.key). I did not test this, gunnarbeutner just suggested it some minutes ago.

    I'll tinker a bit with it, and update the linked Github issue. I have the feeling that certificates created with 2.3.8 will now fail (round about 2015).

  • Thank You very much, i created a new ca.crt with the commands from Your link

    1. openssl x509 -x509toreq -in /var/lib/icinga2/ca/ca.crt -signkey /var/lib/icinga2/ca/ca.key -out /tmp/ca.csr
    2. openssl x509 -in /tmp/ca.csr -out /tmp/ca.crt -signkey /var/lib/icinga2/ca/ca.key -req -days 3650

    and replaced the old ca.crt on the master and on some other clients for testing. So far it looks very good and even the clients with the old ca.crt are working fine.

    Code: The new ca.crt
    1. Certificate:
    2. Data:
    3. Version: 1 (0x0)
    4. Serial Number:
    5. e8:18:fb:6c:f8:b1:21:63
    6. Signature Algorithm: sha256WithRSAEncryption
    7. Issuer: CN=Icinga CA
    8. Validity
    9. Not Before: Aug 23 14:56:01 2017 GMT
    10. Not After : Aug 21 14:56:01 2027 GMT

    My Debian 9 VM for testing is not reachable until tomorrow morning, so i will test it on this machine tomorrow morning, but I am very sure that its will work too.

    Thanks for your support !

  • I'd suggest signing the CA certificate with "icinga2 pki sign-csr" as this involves setting the proper extensions.

    1. cd /var/lib/icinga2/ca
    2. openssl x509 -x509toreq -in ca.crt -signkey ca.key -out regenerated-ca.csr
    3. icinga2 pki sign-csr --csr regenerated-ca.csr --cert regenerated-ca.crt
    4. mv ca.crt ca.crt.borked
    5. mv regenerated-ca.crt ca.crt

    I haven't tested it fully through yet, still checking out which Icinga 2 version is needed to generate faulty certificates here (that involves lots of compiling between major version tags).

    Update: I couldn't reliably reproduce it here, it must be related to the OpenSSL version which was used to generate the CA and certificates back then in 2015.…11#issuecomment-324384804

  • i have a zones.conf.orig still in my icingafolder. It was created on 25.Feb.2015. I pretty sure that this file was created at the moment i used the node wizard to create the master satellite configuration. As I am updating my systems very often i think it was the most recent Debian version at this time.You


    Copy the public CA certificate ca.crt to all your nodes in /etc/icinga2/pki/.

    As far as i can see, this step is not necessary, if your remote node is not affected by the problem, so its possible to "soft-migrate" to the new ca.crt, as the bad certificate on the remote node will still work. You can even run 2.7.0 as long as openssl version is not 1.1.0f or higher.

    The post was edited 3 times, last by unic: to late for my typingskills ().

  • I need to correct myself, the CA regeneration does not work with the icinga2 pki command. This expects to sign a client certificate only and sets the v3 extensions to CA:FALSE, which remains broken.

    A working example is to create an extensions file with a v3 section and set the contraints there, and then reference this inside the CA signing procedure.…11#issuecomment-324384804 (corrected already).


    Your CA certificate doesn't set the v3 extensions and might become invalid, or at least produce warnings.

  • I did some further Testing

    1. cd /var/lib/icinga2/ca
    2. openssl x509 -x509toreq -in ca.crt -signkey ca.key -out regenerated-ca.csr
    3. icinga2 pki sign-csr --csr regenerated-ca.csr --cert regenerated-ca.crt
    4. mv ca.crt ca.crt.borked
    5. mv regenerated-ca.crt ca.crt

    will not work for the remote nodes:

    Code: Remote Node Output
    1. warning/ApiListener: Certificate validation failed for endpoint 'masternode': code 26: unsupported certificate purpose

    This works, but maybe does not have the proper extensions:

    1. cd /var/lib/icinga2/ca
    2. openssl x509 -x509toreq -in ca.crt -signkey ca.key -out regenerated-ca.csr
    3. openssl x509 -in regenerated-ca.csr -out regenerated-ca.crt -signkey ca.key -req -days 5475
    4. #icinga2 pki sign-csr --csr regenerated-ca.csr --cert regenerated-ca.crt
    5. mv ca.crt ca.crt.borked
    6. mv regenerated-ca.crt ca.crt

    I just tested this on Debian 9 and it worked too.


    You don't need to replace ca.crt on the working nodes if you create a new ca.crt. You can wait until you upgrade the old nodes to 2.7.x or upgrade the OS, but then you also need a complete new certificate for the node.

    There is still the question whats about the proper ca.crt extension.

  • Thanks a lot, my post was just to late, haven't seen your last post before i started my post.

    I have recreated the certificate again with your extension settings. All looks very well now.

  • Cool, thanks. This tremendously helps to write a guide for anyone stumbling into this issue. I fear that certificate re-creation is the only way to resolve these openssl problems.