Overview#The Certificate Version field is intended to facilitate orderly changes in Certificate formats over time. version of the encoded certificate. When extensions are used, as expected in this profile, version MUST be 3 (value is 2). If no extensions are present, but a UniqueIdentifier is present, the version SHOULD be 2 (value is 1); however, the version MAY be 3.
Generation of version 2 certificates is not expected by implementations based on this profile.
This field is used mainly for marketing purposes to claim that software is X.509v3 compliant (even when it isn't). The default version is v1(0), if the issuerUniqueID or subjectUniqueID are present than the version must be v2(1) or v3(2). If extensions are present than the version must be v3(2). An implementation should target v3 certificates, which is what everyone is moving towards.
Note that the version numbers are one less than the actual X.509 version because in the ASN.1 world you start counting from 0, not 1 (although it's not necessary to use sequences of integers for version numbers. X.420, for example, is under the impression that 2 is followed by 22 rather than the more generally accepted 3).
If your software generates v1 certificates, it's a good idea to actually mark them as such and not just mark everything as v3 whether it is or not. Although no standard actually forbids marking a v1 certificate as v3, backwards- compatibility (as well as truth-in-advertising) considerations would indicate that a v1 certificate should be marked as such.PEM is the X.509 default which has a value of zero (0), indicating the 1988 version. PEM implementations are encouraged to accept later versions as they are endorsed by CCITT/ISO.