OpenSSL, basic configuration, new_certs_dir, certs

configurationopenssl

I've searched for an answer for the differences and using for these two configuration parameters in the openssl-config-file.

certs         = ... # Where the issued certs are

and

new_certs_dir = ... # default place for new certs

In the Network Security with OpenSSL O'Reilly book also these two parameters in the default-openssl-config-file, but the certs is never used and never described.
By my tests with openssl, all certificates are stored in the folder – defined by new_cers_dir.

What is the difference between these two parameters?
And is the parameter certs used somewhere?

Best Answer

As shown in the documentation

https://www.openssl.org/docs/man1.1.0/apps/ca.html

new_certs_dir is used by the CA to output newly generated certs.

certs is not used here. However its referenced in the demoCA: "./demoCA/certs - certificate output file" Certs is ALSO not used for certificate chains as shown here:

https://www.openssl.org/docs/man1.1.0/apps/pkcs12.html or https://www.openssl.org/docs/man1.1.0/apps/verify.html

Note that /etc/ssl/certs is the default location for issued certs. But the certs variable is $dir/certs so it would be ./demoCA/certs I think we all agree its for issued certs specific to the CA. This makes sense because the CA might be signing certs that are chained to certs not yet issued by any public cert authority.

But where is the documentation for this? I believe its an artifact of the configuration file. It use to be used for options like certificate which would hold the ca.pem within certs so certificate=$certs/ca.pem.

I vaguely recall having this exact same question until I realized it was used later in the config file but now its not.

Edit: It gets weirder. The current version of ca.c here: https://github.com/openssl/openssl/blob/master/apps/ca.c does not reference certs. But much older versions such as this: https://github.com/openssl/openssl/blob/d02b48c63a58ea4367a0e905979f140b7d090f86/apps/ca.c Reference it but do nothing with it.

Related Solutions

RSA 2048 keypair generation: via openssl 0.5s via gpg 30s, why the difference

GnuPG consumes several bytes from /dev/random for each random byte it actually uses. You can easily check that with this command:

start cmd:> strace -e trace=open,read gpg --armor --gen-random 2 16 2>&1 | tail
open("/etc/gcrypt/rngseed", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("/dev/urandom", O_RDONLY)          = 3
read(3, "\\\224F\33p\314j\235\7\200F9\306V\3108", 16) = 16
open("/dev/random", O_RDONLY)           = 4
read(4, "/\311\342\377...265\213I"..., 300) = 128
read(4, "\325\3\2161+1...302@\202"..., 172) = 128
read(4, "\5[\372l\16?\...6iY\363z"..., 44) = 44
open("/home/hl/.gnupg/random_seed", O_WRONLY|O_CREAT, 0600) = 5
cCVg2XuvdjzYiV0RE1uzGQ==
+++ exited with 0 +++

In order to output 16 bytes of high-quality entropy GnuPG reads 300 bytes from /dev/random.

This is explained here: Random-Number Subsystem Architecture

Linux stores a maximum of 4096 bytes (see cat /proc/sys/kernel/random/poolsize) of entropy. If a process needs more than available (see cat /proc/sys/kernel/random/entropy_avail) then the CPU usage becomes more or less irrelevant as the feeding speed of the kernel's entropy pool becomes the relevant factor.

Why openssl s_client verifies a cert against a mismatching CAfile

It turns out that the openssl s_client on Ubuntu 10.04 still queries a default location for system installed certificates, even if -CApath and -CAfile are specified:

8466  open("/usr/lib/ssl/certs/4e18c148.0", O_RDONLY) = 4

(strace output)

Where:

$ ls -l /usr/lib/ssl/certs/4e18c148.0
lrwxrwxrwx 1 root root 30 2014-04-11 21:50 /usr/lib/ssl/certs/4e18c148.0 ->
    Deutsche_Telekom_Root_CA_2.pem

The directory /usr/lib/ssl/certs is a symlink to /etc/ssl/certs on Ubuntu 10.04, thus the open line from the strace log is not selected when grepping for '/etc/ssl' ...

Source

Looking at the openssl-0.9.8k, the source of this issue is located in crypto/x509/by_dir.c, dir_ctrl():

dir=(char *)Getenv(X509_get_default_cert_dir_env());
if (dir)
    ret=add_cert_dir(ld,dir,X509_FILETYPE_PEM);
else
    ret=add_cert_dir(ld,X509_get_default_cert_dir(),
                     X509_FILETYPE_PEM);

Where X509_get_default_cert_dir returns /usr/lib/ssl/certs and X509_get_default_cert_dir_env returns SSL_CERT_DIR.

Workaround

Thus, one can use following workaround under Ubuntu 10.04/openssl 0.9.8k to get the expected behavior:

$ SSL_CERT_DIR="" openssl s_client -crlf -verify 9 \
    -CAfile /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.crt \
    -starttls smtp -host mx-ha03.web.de -port 25

And with the verification fails:

Verify return code: 19 (self signed certificate in certificate chain)

Current Situation

This is a Ubuntu issue. For example, with the Fedora 20's openssl 1.0.1e or Fedora 29's openssl 1.1.1, this workaround is not necessary, because the issue cannot be reproduced. That means when specifying an option like -CAfile or -CApath, no default certificate system directory is added to the directory search list on Fedora systems.

On Ubuntu 16 with openssl 1.0.2g the issue is still present.

It's also present on CentOS 7 with openssl-1.0.2k-16 - and unfortunately, the above workaround doesn't help there and the gnutls-3.3.29-8 fails due to unknown/unexpected TLS packet types.