Need more control on the Local CA parameters

Forums Network Management Request a new feature Need more control on the Local CA parameters

  • This topic is empty.
Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • #44224

    Good morning.

    In the ZS GUI, section X.509CA / Setup, there are 3 parameters available for the certificates to be generated by the Local CA:
    – key size in bits,
    – validity in days,
    – visibility on the logon page.

    The most urgent to add imho is the signing algorithm (SHA1 will be deprecated soon).

    Then some fields are not set in the certificates, causing remarks from the browser: “the web site provides no info about its organization”.

    I also noticed that the SAN of the certificate features multiple IP, some of them obsolete, and others that should not be disclosed.

    Digging in /etc/ssl/openssl.cnf is dirty and may conflict with the GUI. There is also a hardcoded line option -sha512 somewhere in a kerbinet script…

    So I think that the GUI for the Local CA should enable to edit a full template for the certificates to be generated.

    Thanks, Best regards.


    At the very least, the “default_md” setting in the openssl.cnf should be changed to “sha256”



    I tried again but could not find.

    In /etc/ssl/openssl.cnf the directives for SAN are all commented:

    # This stuff is for subjectAltName and issuerAltname.
    # Import the email address.
    # subjectAltName=email:copy
    # An alternative to produce certificates that aren't
    # deprecated according to PKIX.
    # subjectAltName=email:move

    There is no section alt_names…

    But the host certificates generated have a SAN with IPs, some of them removed ages ago, and no longer existing in the DNS area:

    X509v3 extensions:
    X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication
    X509v3 Subject Alternative Name:
    DNS:zzzzz.domain.tld, IP Address:192.168.yyy.2, IP, IP, IP, IP...

    Did somebody find where and how it does that ? Of course it works, but this is messy.

    Thanks, Best regards.


    Hello PatrickB,
    i have tried out to implement the message digest functionality into ZS 3.4.
    But i have no chance to do this, because the glue for tags is hardcoded into /usr/local/apache2/cgi-bin/kerbynet program. πŸ™
    At this moment use all certificate generation the sha256 message digest algorithm, because it’s my hardcoded fallback.
    Any digest selection into gui hasn’t effect on certificate generation.
    I have changed this files:


    New defines into templates are: [DF]MD[md[2|5]|mdc2|rmd160|sha|sha[1|224|256|384|512]]
    for example:


    analog to tags [DF]Key[512|1024|2048].
    The new tag names are “digest” and “DefaultDigest” for example:


    <option ...


    Into scripts i have use the variable DIGEST and read or set the default message digest value below: /var/register/system/ssl/ca/digest.

    IMHO you must implement

      value transfer from templates into ../register/…/digest
      read out the digest from root ca and write into ../register/…/digest after import from external source
      read out value from../register/…/digest and marked appropriate tag as selected

    Let me know, if you interested in.
    PS: As PatrickB already remarked, can you say me why do you use -sha512 into host certificate generations (see at file x509_createDefaultCert) ?

    Best regards


    Good morning & Happy New Year !

    Yes there are people tuning their ZS early on New Year Day πŸ˜†

    Thanks Garfield, It helped me to find some items from my initial questions.

    * The source data for the CA appear to be there:

    root@janus2> ll /var/register/system/ssl/ca
    total 32K
    -rw-r–r– 1 root root 6 Sep 28 2004 StateOrProvince
    -rw-r–r– 1 root root 3 Jan 29 2015 WebExport
    -rw-r–r– 1 root root 4 Nov 19 2004 countryName
    -rw-r–r– 1 root root 3 Jan 29 2015 days
    -rw-r–r– 1 root root 4 Jan 29 2015 keysize
    -rw-r–r– 1 root root 9 Sep 28 2004 localityName
    -rw-r–r– 1 root root 5 Sep 28 2004 organizationName
    -rw-r–r– 1 root root 7 Sep 28 2004 organizationalUnitName

    As you can see, most of them were not updated when I installed my own LocalCA, this is a bit dirty, but not critical…

    * What is used from the CA info:

    The ‘kerbynet.cgi/scripts/x509_createAdminCert’ and ‘…/x509_createDefaultCert’ both use only:

    NBIT=`cat $REGISTER/system/ssl/ca/keysize 2>/dev/null`
    DAYS=`cat $REGISTER/system/ssl/ca/days 2>/dev/null`
    [ -z "$NBIT" ] && NBIT=1024
    [ -z "$DAYS" ] && DAYS=365

    * How the SAN is built (by ‘…/x509_createDefaultCert’):

    echo -n "subjectAltName = DNS:`hostname`" >> $TMP
    find /var/register/system/net/interfaces/ -name IP -type f -exec awk '{printf(", IP:%s",$0)}' {} ; >> $TMP

    This is awful because:
    – the files “…/net/interfaces/…/IP” appears to have kept obsolete IP addresses,
    – this can disclose my LAN side IP’s in certificates made for WAN side,
    – this will not let me specify a wanted name for a given certificate.

    How to change that ?

    It is always the problem with GUIs: you need to either hardcode or write a complex editor for data that most of people won’t care of, so it is often painful job for nothing…

    The simplest solution is always declarative, in the form of a template file located in a known place, with severe warnings to edit it, either by hand or with a GUI file editor…

    For the set of IP addresses, I understand the need to fetch them in the system, but it should be done only once when changes are done in the network structure, and the admin should be able to willingly copy and filter the result.

    OK, now I have found where to hack to have clean certificates.

    More ideas for usability

    Directly using opensssl is tricky, but there is a nice software named XCA that enables anybody a bit aware of the principles to safely and cleanly manage all his SSL data.

    Wouldn’t it be simpler to enable to import all the SSL items into ZS this way ? Actually ZS wants to have its CA and to make its host and admin certificates by itself… with the issues above.

    And since I have twin ZS systems, you imagine that it means 2 CAs πŸ™‚

    This leads me to remind this question, I’d like to have your positions:

    Thanks, Best regards.



    I can confirm that I could take the control of the SAN of the host certificate by adjusting x509_createDefaultCert this way:

    At first I copied the script to some /opt/mods and updated the PostBoot script to replace the original one with it at every reboot (like other mods).

    Then I did that inside (simple hardcode, I could also read them from a file):

    openssl req -new -batch -newkey rsa:$NBIT -nodes -out /tmp/x509default.req -keyout /tmp/x509default.key -days $DAYS -sha512 -subj "/OU=Hosts/CN=$HOSTNAME"
    cat $SSLDIR/extensions > $TMP
    echo -n "subjectAltName = DNS:`hostname`" >> $TMP
    # No I don't want the IP in the certificate:
    # find /var/register/system/net/interfaces/ -name IP -type f -exec awk '{printf(", IP:%s",$0)}' {} ; >> $TMP
    # Instead I want some more names:
    echo -n ", DNS:janus.mydomain.lan," >> $TMP
    echo >> $TMP
    openssl ca -batch -days $DAYS -in /tmp/x509default.req -out /tmp/x509default.cert -extfile $TMP -extensions host

    I use XCA on a separate machine to generate all my certificates and their keys. Notably the intermediate CA (and its key) for the ZS. The master CA (which signed the intermediate CA) is just imported as a trusted certificate, without its ultra-precious key of course ! πŸ˜›

    When importing the intermediate CA, the ZS process regenerates the host certificate and thanks to the change, it has the SAN I need. After a reboot, all is clean 8)

    At this time I did not try all the scenarios of certificate renewal from the ZS GUI. I hope there are no other paths likely to bring back the original pattern πŸ‘Ώ

    In this case, a more aggressive solution 😈 would be to abandon the whole certificate management from the GUI and code a tool script this way:
    …to import all the certificates from outside and force them into the right places inside ZS. I hope I will escape that 😑

    NB: While doing such things, on the computer used to access ZS’ GUI your browser may become very boring, especially Firefox (it does its job) with certificate errors, and even forbid you to complete the operation 😈
    Internet Explorer is a bit more permissive: it screams but always has an option to bypass… On Firefox, you may have to purge the (local) certificate database: a file named cert8.db in the profile + the cache. After that you just will have to reimport your personal certificates: added CA etc. this is not lethal.

    Best regards.

Viewing 6 posts - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.