Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set notBefore/notAfter to the beginning of the year to issuing certificate (v2) #550

Merged
merged 2 commits into from
May 3, 2022

Conversation

ValdikSS
Copy link
Contributor

This patch adds nodatetime option to build-client-full and build-server-full commands which generates certificates with "notBefore" set to the beginning of the year (01 January 00:00:00) and "notAfter" to the day of which CA certificate is issued, with the difference only in year.
It could be useful for a VPN service to prevent client and server certificate generation date and time disclosure.

This modification adds "nodatetime" argument to build-client-full
and build-server-full which issues the certificate with notBefore
and notAfter date set to 1 Jan, with difference in the year only.

It could be useful for a VPN service to prevent client and server
certificate generation date and time disclosure.
@ValdikSS
Copy link
Contributor Author

cert_dates commands tested on Linux and Busybox, not tested on Darwin/BSD, but looks fine.

@TinCanTech TinCanTech self-assigned this Apr 29, 2022
@TinCanTech TinCanTech added this to the v3.1.0 milestone Apr 29, 2022
@TinCanTech TinCanTech removed this from the v3.1.0 milestone Apr 30, 2022
@TinCanTech TinCanTech added the development Possible changes label Apr 30, 2022
@TinCanTech
Copy link
Collaborator

TinCanTech commented May 2, 2022

@ValdikSS I appreciate the work you have done here.

The problem is, I think setting the CA creation date as the certificate expiration date is not such a good idea. Sorry for that suggestion.

I would prefer this to work like so:

easyrsa --fix-date-offset=123 build-server-full server nopass

--fixed-date-offset would have a value of 0-366 (366 -> leap year).
The name could have an alias --fixdate or something similar.

How does that sound ?

Edit: This is not right either ..

@TinCanTech
Copy link
Collaborator

TinCanTech commented May 2, 2022

Your goal is to set certificate dates notBefore and notAfter to a preset date. To hide the real generation date.

Setting the notBefore date to 01/01/YYYY is good.
Setting the notAfter date needs to be configurable. Otherwise, it's a New Years Day disaster..

Therefore, notAfter =

  • notBefore (Always Jan, 1st THIS year)
  • Plus $EASYRSA_CERT _EXPIRE (Divided by 365 = Number of years: Note 1)
  • Plus $offset (Value between 0-366)

Note 1:

$EASYRSA_CERT_EXPIRE would be set to 730

$ echo $(( 825 / 365 )) # EASYRSA_CERT_EXPIRE default = 825
2
$ echo $(( 2 * 365 ))
730

How does that sound ?

@TinCanTech
Copy link
Collaborator

I have a patch, which fixes your patch.

I can merge this as-is and fix 🍰 🍻

or you can fix this. 🔥 🎱

@TinCanTech TinCanTech added this to the v3.1.0 milestone May 3, 2022
TinCanTech added a commit that referenced this pull request May 3, 2022
The initial idea was to mask the actual certificate creation date.
The reason was to further anonymise user certificates. (YMMV)

There is now a second part to this date "fixing":
* This allows for all certificates to expire on the same day.

Using command option '--fix-offset=nnn', all certificates will be created
* with a 'notBefore' date of January 1st of the current year.
* with a 'notAfter' date of the day-of-year number from '--fix-offset',
  in the final year, as per EASYRSA_CERT_EXPIRE (Default 825 days).
  The default 825 days results in 2 years plus the offset given.

This can also be set in the 'vars' file, for convenience.

The default day-of-year offered is 183; either July 2 or 3 (leap year).

Follow-up to: #550 (Replaces 'nodatetime' with '--fix-offset')

Signed-off-by: Richard T Bonhomme <tincantech@protonmail.com>
@TinCanTech TinCanTech merged commit 1620cfe into OpenVPN:master May 3, 2022
@ValdikSS
Copy link
Contributor Author

ValdikSS commented May 4, 2022

Your modifications LGTM, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants