5 ms·

What’s the recommended practice for CN on a certificate with multiple SANs? I imagine many tools and org process still require at least some value to be present

What’s the recommended practice for CN on a certificate with multiple SANs? I imagine many tools and org process still require at least some value to be present.

tialaramex 6y ago
The issuing CA is required to pick one of the SANs to encode as CN if it is to be present at all in a leaf certificate. You may be able to choose (so long as you obey this constraint) by setting your desired CN in the Certificate Signing Request. If you meant how should you pick? Well that's up to you. From a presentation point of view, the CN may be used to display the certificate's subject in some summary views so you might want a short but sufficient name to describe what it's for, if it also includes aliases that are more confusing or less specific. From a compatibility point of view, older software might (erroneously as this article points out, PKIX introduced SANs over twenty years ago, time to upgrade) only check CN and so you might want to reserve the CN to be for a name used by the oldest crumbliest clients. If you've got archaic.mycorp.example and modern.mycorp.example and experimental.mycorp.example with archaic still offering TLS 1.0 and 3DES to that valuable yet tragically slow to upgrade customer who insists on it, well I'd put archaic.mycorp.example in the CN field because if there's a client that'll expect it there it'd be the one that's still needing TLS 1.0 or 3DES not the one built last week. Another compatibility idea, don't put the obvious name in the CN for the test servers, use some other name you own that's harmless - this way people integrating your system will run into the "It doesn't work because our crappy library doesn't do SANs" problem during early testing not when it goes to production or some day when your production certificates change the value of CN.

5 ms·

What’s the recommended practice for CN on a certificate with multiple SANs? I imagine many tools and org process still require at least some value to be present

by pimlottc 6y ago

What’s the recommended practice for CN on a certificate with multiple SANs? I imagine many tools and org process still require at least some value to be present.

tialaramex 6y ago
The issuing CA is required to pick one of the SANs to encode as CN if it is to be present at all in a leaf certificate. You may be able to choose (so long as you obey this constraint) by setting your desired CN in the Certificate Signing Request. If you meant how should you pick? Well that's up to you. From a presentation point of view, the CN may be used to display the certificate's subject in some summary views so you might want a short but sufficient name to describe what it's for, if it also includes aliases that are more confusing or less specific. From a compatibility point of view, older software might (erroneously as this article points out, PKIX introduced SANs over twenty years ago, time to upgrade) only check CN and so you might want to reserve the CN to be for a name used by the oldest crumbliest clients. If you've got archaic.mycorp.example and modern.mycorp.example and experimental.mycorp.example with archaic still offering TLS 1.0 and 3DES to that valuable yet tragically slow to upgrade customer who insists on it, well I'd put archaic.mycorp.example in the CN field because if there's a client that'll expect it there it'd be the one that's still needing TLS 1.0 or 3DES not the one built last week. Another compatibility idea, don't put the obvious name in the CN for the test servers, use some other name you own that's harmless - this way people integrating your system will run into the "It doesn't work because our crappy library doesn't do SANs" problem during early testing not when it goes to production or some day when your production certificates change the value of CN.