Don’t do this at home - Wild Domino 12.0.1 CertMgr configurations

Daniel Nashed  17 December 2021 19:24:25

Domino 12 CertMgr is around for a while and got cool new features in 12.0.1 like exportable keys.
But let me show you something today that is already in Version 12.0.

It's not explicitly documented. But because it is designed for flexibility, there are wild configurations you could run.
I am running it with internet domains hosted at different providers with different DNS TXT APIs in production since the early Domino 12.0 beta phase.
Let me share a certificate request I setup demoing it for a friend today spanning multiple providers...

Multiple ACME providers supported. New in 12.0.1: SSL.COM

I am also using different types of ACME providers -- Starting with 12.0.1 also SSL.COM is supported ( there was a minor change needed to support their way to use external account binding - aka EAB).
In my example I am using ZeroSSL. But the same works also with Let's Encrypt and other ACME providers.
ACME is a standard with some extensions to register at providers. ZeroSSL and SSL.COM require this external account binding (EAB).




Using multiple DNS TXT APIs for different domains -- at the same time!


In my domain I am using multiple DNS TXT APIs at different providers.
They are all available using the HCL GitHub repository --> https://github.com/hCL-TECH-SOFTWARE/domino-cert-manager

Here is a list of the domains I am using for testing.
Digital Ocean is a sub domain delegation using their DNS API with their DNS service pointing name server entries to an account it Digital Ocean.
And I also leveraging the deSEC provider I blogged about recently.



Create TLS Credentials for multiple domains hosted at multiple providers

In my example I am creating a certificate for multiple SANs (subject alternate names) hosted at different providers.
The DNS entry www.nashed.de does not have a DNS API configured and uses a HTTP-01 challenge.
All other SANs map to domains, which trigger a DNS-01 challenge for an account on different DNS providers/accounts.

Here is how the TLS Credentials document looks like:




Once you submit the request you see CertMgr starts a single ACME request with ZeroSSL.
During that operation ZeroSSL asks to place 6 DNS-01 challenges and one HTTP-01 challenge.

Here is the log showing the operations performed:

17.12.2021 19:44:14   CertMgr: Waiting 80 seconds before confirming [HTTP-01: 1] [DNS-01: 6] challenge(s) are in place ..


The HTTP-01 is the fastest operation. The challenge is placed into certstore.nsf and is waiting for validation via HTTP request (now in 12.0.1 with the embedded challenge validation replacing the DSAPI filter).
In parallel you can see that different domains use different DNS API accounts to bring TXT records in place for the DNS challenges.

I could even have added wild-card SAN names for those DNS-01 validated SANs. Or have used IDNs with umlauts or other international chars.


Here is the list of DNS-01 challenges CertMgr creates during the ACME flow:




Once all challenges are in place and CertMgr confirms the challenge via ACME protocol, a CSR is send to ZeroSSL and a certificate is issued from ZeroSSL.
You can see the result above in the TLS Credentials document. And you can look into details in the dump below.


Conclusion/Summary

CertMgr uses the ACME standards with all the different options available and you can mix and match what you need using different providers.
Once configured CertMgr triggers the right operation in back-end. And the logs show all the details if needed.

No you don't have to use all those different providers at once for one SSL certificate. I am just trying to show how it works and what is possible also for different SSL certificates you request.

Most other ACME integrations are command-line driven. CertMgr comes with a modern UI with all the options available directly in the cerstore.nsf.
This makes CertMgr a very powerful tool for managing external certificates in your Domino environment and also for other applications.

With the new exportable keys introduced in Domino 12.0.1 you can use the SSL certificates also in other environments to take benefit of this flexibility.



-------------------------------------------------

Here is the log. they are using a intermediate CA which is already a ECDSA NIST P-384 key and the signature for my ECDSA key is ecdsa-with-SHA384.

#0
Subject    : www.nashed.de
SAN        : www.nashed.de, zerossl.csi-domino.com, zerossl.digitalocean.domino-lab.net, zerossl.domino-lab.net, zerossl.domino.dedyn.io, zerossl.nashcom.de, zerossl.nashcom.org
Issuer     : AT/ZeroSSL/ZeroSSL ECC Domain Secure Site CA

Not Before : 2021.12.17 00:00:00
Not After  : 2022.03.17 23:59:59 (expires in 90.0 days)

Serial     : 4DB681AE1764F170DC94506FCD8D1413
Sign Alg   : ecdsa-with-SHA384
KeyUsage   : DigitalSignature
Extensions : BasicConstraints, KeyUsage, ExtKeyUsage
ExtKeyUsage: TLS Web Server Authentication, TLS Web Client Authentication
Key        : ECDSA NIST P-256
ASN1 OID   : prime256v1

OCSP       : http://zerossl.ocsp.sectigo.com
AuthInfoURL: http://zerossl.crt.sectigo.com/ZeroSSLECCDomainSecureSiteCA.crt

AuthKeyId  : 0F:6B:E6:4B:CE:39:47:AE:F6:7E:90:1E:79:F0:30:91:92:C8:5F:A3
SubjKeyId  : 38:22:A8:1C:F1:97:2C:ED:7F:3A:6D:85:69:CC:7B:1B:C9:B6:7D:0C
MD5        : 4A:F7:05:F2:23:0B:C1:3D:30:CC:8A:8C:AD:F9:91:E1
SHA1       : D5:9C:34:86:29:01:2D:C4:8A:F3:8B:83:D4:50:41:6A:08:9D:8D:6E
SHA256     : 77:08:06:66:F8:85:09:B0:62:3F:F7:BD:22:68:95:56:35:33:9D:2B:EE:F9:8C:35:DD:A9:FA:57:4D:6E:31:12

-----BEGIN CERTIFICATE-----
MIIEljCCBBygAwIBAgIQTbaBrhdk8XDclFBvzY0UEzAKBggqhkjOPQQDAzBLMQsw
CQYDVQQGEwJBVDEQMA4GA1UEChMHWmVyb1NTTDEqMCgGA1UEAxMhWmVyb1NTTCBF
Q0MgRG9tYWluIFNlY3VyZSBTaXRlIENBMB4XDTIxMTIxNzAwMDAwMFoXDTIyMDMx
NzIzNTk1OVowGDEWMBQGA1UEAxMNd3d3Lm5hc2hlZC5kZTBZMBMGByqGSM49AgEG
CCqGSM49AwEHA0IABIxuIQtuNrmJDiKndV5YNCpvxKzcpt4ULw7arKyhiN+oEyV1
RAkmndQivP8talOu7HPpfE87W0sffnMtgQEsMsejggMTMIIDDzAfBgNVHSMEGDAW
gBQPa+ZLzjlHrvZ+kB558DCRkshfozAdBgNVHQ4EFgQUOCKoHPGXLO1/Om2Facx7
G8m2fQwwDgYDVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYI
KwYBBQUHAwEGCCsGAQUFBwMCMEkGA1UdIARCMEAwNAYLKwYBBAGyMQECAk4wJTAj
BggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwCAYGZ4EMAQIBMIGI
BggrBgEFBQcBAQR8MHowSwYIKwYBBQUHMAKGP2h0dHA6Ly96ZXJvc3NsLmNydC5z
ZWN0aWdvLmNvbS9aZXJvU1NMRUNDRG9tYWluU2VjdXJlU2l0ZUNBLmNydDArBggr
BgEFBQcwAYYfaHR0cDovL3plcm9zc2wub2NzcC5zZWN0aWdvLmNvbTCCAQQGCisG
AQQB1nkCBAIEgfUEgfIA8AB2AEalVet1+pEgMLWiiWn0830RLEF0vv1JuIWr8vxw
/m1HAAABfcm4TAQAAAQDAEcwRQIhAKjEjl74CIX0eDQoPpZ9oJf70LQJJ5jieuoV
SCcv6iWdAiAqJAV3bM+tIV51NEZW1lD223XzqH5XMNE6/RS2/Ixs0wB2AEHIyrHf
IkZKEMahOglCh15OMYsbA+vrS8do8JBilgb2AAABfcm4TDAAAAQDAEcwRQIhAJPz
q0xi7UESWiBzKWMLx3viU/xqq2BAr3GvGdbFSDLmAiANH6NGpXr+d5meJK95IpFs
HD0qt48xrbe25q2jVunS7TCBsQYDVR0RBIGpMIGmgg13d3cubmFzaGVkLmRlghZ6
ZXJvc3NsLmNzaS1kb21pbm8uY29tgiN6ZXJvc3NsLmRpZ2l0YWxvY2Vhbi5kb21p
bm8tbGFiLm5ldIIWemVyb3NzbC5kb21pbm8tbGFiLm5ldIIXemVyb3NzbC5kb21p
bm8uZGVkeW4uaW+CEnplcm9zc2wubmFzaGNvbS5kZYITemVyb3NzbC5uYXNoY29t
Lm9yZzAKBggqhkjOPQQDAwNoADBlAjEAwO6lWcIQncwFLwYE5v7Vy3HteftBs3hh
SccRE+mYcTJCe6cHBzmrHMQD1PeZ9MmjAjAazzp+skaROIKcbsedWgbppcEdtTda
sX/WF/SYMzaSVC3QvELUES9zM1SzLkKyHnI=
-----END CERTIFICATE-----

#1
Subject    : AT/ZeroSSL/ZeroSSL ECC Domain Secure Site CA
Issuer     : US/New Jersey/Jersey City/The USERTRUST Network/USERTrust ECC Certification Authority

Not Before : 2020.01.30 00:00:00
Not After  : 2030.01.29 23:59:59 (expires in 8.1 years)

Serial     : 23B76DE3C1BB2B1A51961E08EAB764E8
Sign Alg   : ecdsa-with-SHA384
KeyUsage   : DigitalSignature, CrlSign
Extensions : BasicConstraints, CA, KeyUsage, ExtKeyUsage
PathLen    : 0
ExtKeyUsage: TLS Web Server Authentication, TLS Web Client Authentication
Key        : ECDSA NIST P-384
ASN1 OID   : secp384r1

AuthInfoURL: http://crt.usertrust.com/USERTrustECCAddTrustCA.crt
CRL        : http://crl.usertrust.com/USERTrustECCCertificationAuthority.crl

AuthKeyId  : 3A:E1:09:86:D4:CF:19:C2:96:76:74:49:76:DC:E0:35:C6:63:63:9A
SubjKeyId  : 0F:6B:E6:4B:CE:39:47:AE:F6:7E:90:1E:79:F0:30:91:92:C8:5F:A3
MD5        : EE:39:38:0F:32:5C:F0:C5:1F:4C:6F:7B:E0:A4:C8:99
SHA1       : 7F:95:27:6D:49:51:49:9F:D7:56:DF:34:4A:A2:4F:B3:8C:EA:F6:78
SHA256     : 5D:D6:61:D3:CB:33:B5:00:5C:BE:D0:45:A2:23:DD:C4:44:5A:AA:41:D1:AC:B5:DF:70:08:84:CA:D9:BA:41:95

-----BEGIN CERTIFICATE-----
MIIDhTCCAwygAwIBAgIQI7dt48G7KxpRlh4I6rdk6DAKBggqhkjOPQQDAzCBiDEL
MAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0plcnNl
eSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNVBAMT
JVVTRVJUcnVzdCBFQ0MgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMjAwMTMw
MDAwMDAwWhcNMzAwMTI5MjM1OTU5WjBLMQswCQYDVQQGEwJBVDEQMA4GA1UEChMH
WmVyb1NTTDEqMCgGA1UEAxMhWmVyb1NTTCBFQ0MgRG9tYWluIFNlY3VyZSBTaXRl
IENBMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAENkFhFytTJe2qypTk1tpIV+9QuoRk
gte7BRvWHwYk9qUznYzn8QtVaGOCMBBfjWXsqqivl8q1hs4wAYl03uNOXgFu7iZ7
zFP6I6T3RB0+TR5fZqathfby47yOCZiAJI4go4IBdTCCAXEwHwYDVR0jBBgwFoAU
OuEJhtTPGcKWdnRJdtzgNcZjY5owHQYDVR0OBBYEFA9r5kvOOUeu9n6QHnnwMJGS
yF+jMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQW
MBQGCCsGAQUFBwMBBggrBgEFBQcDAjAiBgNVHSAEGzAZMA0GCysGAQQBsjEBAgJO
MAgGBmeBDAECATBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVz
dC5jb20vVVNFUlRydXN0RUNDQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwdgYI
KwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVzZXJ0cnVzdC5j
b20vVVNFUlRydXN0RUNDQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6
Ly9vY3NwLnVzZXJ0cnVzdC5jb20wCgYIKoZIzj0EAwMDZwAwZAIwJHBUDwHJQN3I
VNltVMrICMqYQ3TYP/TXqV9t8mG5cAomG2MwqIsxnL937Gewf6WIAjAlrauksO6N
UuDdDXyd330druJcZJx0+H5j5cFOYBaGsKdeGW7sCMaR2PsDFKGllas=
-----END CERTIFICATE-----

...

• Comments [0]