Daniel Nashed's Blog

Domino running RSA and ECDSA keys at the same time

Domino V12 introduced ECDSA support. But you will still also need RSA keys in most cases, because not every client is able to handle ECDSA keys and corresponding ciphers.
This means you need to have both keys configured at the same time.
Depending on how you map your TLS Credentials via server doc/internet sites, it might not work for you as expected.

Let me try to explain how the new TLS Cache works and which options you have.


When you looked into the betas you noticed that HCL tried to get rid of the "kyr"-file names completely.
The physical files are not needed any more and the certificates and keys are stored and distributed securely in certstore.nsf.
But some kind of mapping is needed between the internet site and the TLS Cache which is serving the TLS Credentials for each servertask separately.


Mapping TLS Credentials


If a client is not using SNI (server name indication) to indicate the server to use, the mapping to the internet site can only be done by either IP address or default internet site.
And in this case the internet task involved (for example HTTP) can only use the keyfile name configured to lookup the right TLS Credentials document.

So the name passed is the value set in the keyfile name field in the internet site or server document.

This keyfile/tag lookup is similar to what you know from earlier Domino releases -- It just checks the first keyfile name matching.
There is no special logic to handle multiple key file names -- or wildcards -- when performing keyfile lookups.

--> This means you should never specify the same keyfile name for two TLS Credentials documents for the same Domino server.

With a mixed environment with Domino V12 and earlier servers specifying the name "keyfile.kyr" in one internet site/server document to define the default TLS Credentials uses is the safest bet.
You have to specify the same keyfile.kyr name in the TLS credentials document to have a direct lookup mapping.


Your configuration for the RSA TLS Credential document could look like this:





Default key used if no key found


The TLS Cache also tries to provide a default kyr file for RSA and ECDSA separately.
Because a server cannot just map any key in the wild, only certain keys are used as default keys.

• Hostname specified in the server document
  
• TLS Credentials specifying the default "keyfile.kyr" (with exactly this default name) are selected as default TLS Credentials.

But this should be just the last resort if no other mapping works.
I would always recommend to ensure all requests are mapped correctly.


Wildcard certificates


For wildcard certificates this can be a tricky configuration. And this differs depending on your environment:


Domino V12 only servers


If all your servers hosting an internet site are Domino V12 and using cerstore.nsf, you can specify the wildcard name like *.nashcom.de in the keyfile name your TLS Credential documents.

This will make sure always the right key is mapped, because hostname lookups have an extended logic including wildcard certificate matching.
The logic used will not only work for SNI requests, but the keyfile name in internet site is matched with the same logic.
Only keyfile names are just matched on first entry found.


Mixed server environment


In a mixed server environment configuring the default keyfile.kyr for the RSA TLS Credential document will ensure always the right key is looked up.
If a server doesn't support ECDSA this will always fall back to RSA in this case.


Mixed requests with RSA and ECDSA


The type of request is determined by the Hash algorithms requested by a client.
The beginning of the handshake does not have this information nor the name of the server.
So the first lookup is always by the keyfile name specified in the server.doc / internet site that is used by default.

If the client passed hash algorithms, this determines the key type used.
If no hash algorithms are specified, by default HTTP uses ECDSA and all other internet protocols will still use RSA if present.

You can change this default behavior via notes.ini if required:

For HTTP --> notes.ini TLSCACHE_HTTP_PREFER_RSA=1
For all other internet protocols, example for SMTP --> notes.ini TLSCACHE_SMTP_PREFER_ECDSA=1

This should usually not be needed, but has been added to ensure all cases are covered.


Logging and testing connections


The parameter CERTSTORE_CACHELOG=1 enables logging/debugging for the TLS Cache.

It will show all parameters from the TLS Cache request and in a second log line return the results.
The same thread should always have two matching lines in console.log

Below you see he first part of the handshake in the first two lines.
The next two lines are the second part of the handshake where you see the requested hash algorithms and the SNI name.


HTTP request


openssl s_client -connect blog.nashcom.de:443

[792026:000012-00007FF22F403700] TLSCache-Log-http: CacheLookupRequest -> Host/Tag: [keyfile.kyr] RSAHashAlgs: 0x0, ECDSAHashAlgs: 0x0, Key: 1, Cert: 1, OCSP: 1 TrustPolicy: 1 DNList: 0
[792026:000012-00007FF22F403700] TLSCache-Log-http: CacheLookupResult: [keyfile.kyr] -> [RSA 4096] Flags: 0x0, RSAHashAlgs: 0x1, ECDSAHashAlgs: 0x1, DefaultAssigned: 0 -> Err: 0x0
[792026:000012-00007FF22F403700] TLSCache-Log-http: CacheLookupRequest -> Host/Tag: [blog.nashcom.de] RSAHashAlgs: 0x7C, ECDSAHashAlgs: 0x7C, Key: 1, Cert: 1, OCSP: 1 TrustPolicy: 1 DNList: 0
[792026:000012-00007FF22F403700] TLSCache-Log-http: CacheLookupResult: [blog.nashcom.de] -> [ECDSA NIST P-256] Flags: 0x0, RSAHashAlgs: 0x7C, ECDSAHashAlgs: 0x7C, DefaultAssigned: 0 -> Err: 0x0


openssl s_client -sigalgs "RSA+SHA256" -connect blog.nashcom.de:443

[792026:000013-00007FF22F201700] TLSCache-Log-http: CacheLookupRequest -> Host/Tag: [keyfile.kyr] RSAHashAlgs: 0x0, ECDSAHashAlgs: 0x0, Key: 1, Cert: 1, OCSP: 1 TrustPolicy: 1 DNList: 0
[792026:000013-00007FF22F201700] TLSCache-Log-http: CacheLookupResult: [keyfile.kyr] -> [RSA 4096] Flags: 0x0, RSAHashAlgs: 0x1, ECDSAHashAlgs: 0x1, DefaultAssigned: 0 -> Err: 0x0
[792026:000013-00007FF22F201700] TLSCache-Log-http: CacheLookupRequest -> Host/Tag: [blog.nashcom.de] RSAHashAlgs: 0x10, ECDSAHashAlgs: 0x0, Key: 1, Cert: 1, OCSP: 1 TrustPolicy: 1 DNList: 0
[792026:000013-00007FF22F201700] TLSCache-Log-http: CacheLookupResult: [blog.nashcom.de] -> [RSA 4096] Flags: 0x0, RSAHashAlgs: 0x10, ECDSAHashAlgs: 0x0, DefaultAssigned: 0 -> Err: 0x0


For SMTP STARTTLS connections you can use a command line like this

openssl s_client -connect mail.nashcom.de:25 -starttls smtp -crlf
openssl s_client -sigalgs "RSA+SHA256" -connect mail.nashcom.de:25 -starttls smtp -crlf
openssl s_client -sigalgs "ECDSA+SHA256" -connect mail.nashcom.de:25 -starttls smtp -crlf

• Comments [3]