www.zeroshell.org Forum Index www.zeroshell.org
Linux Distribution for server and embedded devices
 SearchSearch  RegisterRegister  UsergroupsUsergroups 
 ProfileProfile  Log inLog in  Log in to check your private messagesPrivate Message 

Need more control on the Local CA parameters

Post new topic   Reply to topic    www.zeroshell.org Forum Index -> Request a new feature
View previous topic :: View next topic  
Author Message

Joined: 03 Nov 2012
Posts: 50

PostPosted: Sun Mar 01, 2015 9:08 am    Post subject: Need more control on the Local CA parameters Reply with quote

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.
Back to top
View user's profile Send private message

Joined: 20 May 2015
Posts: 1

PostPosted: Wed May 20, 2015 3:44 pm    Post subject: Reply with quote

At the very least, the "default_md" setting in the openssl.cnf should be changed to "sha256"
Back to top
View user's profile Send private message

Joined: 03 Nov 2012
Posts: 50

PostPosted: Sat Nov 14, 2015 3:11 pm    Post subject: Where to cleanup the settings for certificate generation ? Reply with quote


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 Address:192.168.xxx.1, IP Address:192.168.xxx.2, IP Address:192.168.xxx.4, IP...

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

Thanks, Best regards.
Back to top
View user's profile Send private message

Joined: 17 Jul 2011
Posts: 4

PostPosted: Fri Jan 01, 2016 7:55 am    Post subject: Reply with quote

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 <xvar ...> tags is hardcoded into /usr/local/apache2/cgi-bin/kerbynet program. Sad
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: <xvar ...> [DF]MD[md[2|5]|mdc2|rmd160|sha|sha[1|224|256|384|512]]
for example:
<option value=sha256> <xvar MDsha256>>sha256</option>

analog to <xvar ...> tags [DF]Key[512|1024|2048].
The new <select...> tag names are "digest" and "DefaultDigest" for example:

<select name=digest>
   <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 <option ...> 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
Back to top
View user's profile Send private message

Joined: 03 Nov 2012
Posts: 50

PostPosted: Fri Jan 01, 2016 10:15 am    Post subject: Some parameters located now... Reply with quote

Good morning & Happy New Year !

Yes there are people tuning their ZS early on New Year Day Laughing

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 Smile

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

Thanks, Best regards.
Back to top
View user's profile Send private message

Joined: 03 Nov 2012
Posts: 50

PostPosted: Fri Apr 01, 2016 8:42 pm    Post subject: Take control of the SAN Reply with quote


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, DNS:lan.mydomain.org" >> $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 ! Razz

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 Cool

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 Evil or Very Mad

In this case, a more aggressive solution Twisted Evil 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 Mad

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 Twisted Evil
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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    www.zeroshell.org Forum Index -> Request a new feature All times are GMT
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2005 phpBB Group