mandatory SAN

[nimbius]

most web browsers dont suport a certificate without a SAN defined anymore. can we add a default SAN to match the CN for new certs? thanks!

[TinCanTech]

A SAN is, by definition, an alternative name.

How would you define a default "mandatory" alternative name ?

[nimbius]

sorry for such a terse little issue, i know these arent terribly useful. maybe mandatory is the wrong choice of word too.

rfc2818 specifies Subject Alternative Names as the preferred method of adding DNS names to certificates, deprecating the previous method of putting DNS names in the commonName field. Chrome removed support for checking the commonName field at all about 4-5 years ago, instead only looking at the SANs. firefox naturally balks at certs without a SAN. curl and wget dont seem to mind however.

I think it would be a good idea to take the base name supplied for build-server-full and insert it as a SAN entry, since the base name is often the DNS name of the certificate being generated. this could be an option in vars perhaps.

[TinCanTech]

How would you define a variable alternative name in a global vars file ?

[nimbius]

i suppose i meant the feature. for example:

AUTO_SAN =1 # populate an initial SAN entry for certificates using the base name specified during certificate creation

[TinCanTech]

That would require another command line option, eg. --auto-san.

Which is no improvement over current use of --san=foo.

[nimbius]

how should easyrsa meet rfc2818? is it reasonable to add --san to each invocaction?

[TinCanTech]

how should easyrsa meet rfc2818?

By what contract is EasyRSA compelled to conform to RFC2818 ?

Furthermore, RFC2818 is bound by RFC2459. In its current form EasyRSA does not and cannot comply to RFC2459.

is it reasonable to add --san to each invocaction?

Yes, because there is no specified relationship of CN or DN to SAN. EasyRSA does not make assumptions pertaining to use of names.

If your certificate requires an alternate name then, as CA administrator, that is your responsibility to define, as per what ever conventions you choose to adhere to.

If, by RFC, a standardised relationship between CN/DN to SAN is established then EasyRSA may choose, or not, to comply to that definition.

[nimbius]

The idea was to make the software easier to use so people didnt have to type --san=DNS: every time which is a chore and makes the program tedious to use.

is there an easer way to do this? maybe im going about it wrong.

[TinCanTech]

And how many unique server certificates do you create per day, to make this so tedious ?

[nimbius]

clearly enough to suggest a nice feature like automatic SAN to make the program easier to use :)

I can get to work on a PR if that would help. maybe if --san is specified, then the feature is disabled in favour of the user input instead?

[TinCanTech]

clearly enough to suggest a nice feature like automatic SAN

"clearly", you have not answered the question.

to make the program easier to use :)

Use of --san is explicit and easy.

I can get to work on a PR if that would help.

It would not.

maybe if --san is specified, then the feature is disabled in favour of the user input instead?

Negative - Auto-SAN of unsuitable data will not become default, again..

If you specifically require auto-SAN then please use EasyRSA v3.1.7.

[nimbius]

so it was added, and then removed? why?

[TinCanTech]

why?

Please see: My first reply.

[TinCanTech]

FTR, The intention here is as follows:

When creating a server certificate, the CN from the command line
is intended to be used as the SAN.

Example 1:

$ easyrsa build-server-full www.example.com

This would add a SAN of DNS:www.example.com.
On top of which, the proposal also leaned toward making this
behavior be default. As in EasyRSA v3.1.7

Example 2:

$ easyrsa build-server-full server

Which would add a SAN of DNS:server.
This SAN technically breaks the expected use case cited in RFCs
listed above.

So, this naive version of Auto-SAN must be used correctly to be
of any production value and used incorrectly would likely result
in further breakages, which EasyRSA can do without.

For this and other reasons, automatic SAN is rejected.

If you need a SAN then you "and only you" can provide one.
Do so via option --san (See help for more info).

---

Also, comments like this:

since the base name is often the DNS name of the certificate being generated

are blind assumption and incorrect.

[nimbius]

dude why post this? you had half a dozen opportunities to make this clear, well reasoned statement about the intent and direction of the project and instead chose to turn the discussion into a carnival game I cant win.

if you knew you were never going to support this option, and you knew you had removed it from the code in a prior release, why bother?

[TinCanTech]

Reasons:

• I gave you the opportunity to state your case.
• This discussion can now be referred back to.
• The final comment serves as a reminder for future reference.

---

you had half a dozen opportunities to make this clear, well reasoned statement about the intent and direction of the project

Opportunities that I took, which you chose to over look.

---

instead chose to turn the discussion into a carnival game I cant win

An opportunity to learn... You can't win them all.

Besides, you don't win a discussion. Discussions happen and observers make their own decisions.

All participants are observers but not all observers are participants.

---

Easy-RSA already provides an easy way to use OpenSSL.

Easy-RSA will not cater the level of laziness on display in this feature request.

The option is --san, please use it.

Until there is an RFC which outlines how commonName should influence SAN, this feature will not be accepted as an Easy-RSA feature. Easy-RSA will not pollute all Server certificates with an invalid SAN DNS name, just for the convenience of a few lazy people.

It's just a little bit of history repeating ..

Maybe --auto-san is ok. #1180