Re: [openssl-users] Personal CA: are cert serial numbers critical?

Bonjour, > Le 16 août 2017 à 16:51, Jakob Bohm a écrit : > > On 16/08/2017 16:32, Tom Browder wrote: >> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users >> > wrote: >> >>➢ So, in summary, do I

Re: [openssl-users] keyusage digitalSignature in CA certs

Bonjour, > Le 17 août 2017 à 15:20, Robert Moskowitz a écrit : > > Should digitalSignature be included in keyusage in CA certs? It depends on what you plan to do with the corresponding private key. If you want this private key to sign messages other than certificates and

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

> Le 17 août 2017 à 17:36, Jeffrey Walton a écrit : > > On Thu, Aug 17, 2017 at 11:34 AM, Erwann Abalea > wrote: >> >>> Le 17 août 2017 à 17:26, Jeffrey Walton a écrit : >>> > When you see a name like "example.com" in

Re: [openssl-users] More on cert serialnumbers

Bonjour, > Le 17 août 2017 à 17:10, Robert Moskowitz a écrit : > > > > On 08/17/2017 10:50 AM, Salz, Rich via openssl-users wrote: >> And RFC 5280, which is still the standard, says serial# must be <= 20 bytes. >> Which means, you want to make sure the high bit is off,

Re: [openssl-users] Implementing deprecation of commonname and emailaddress

> Le 17 août 2017 à 17:26, Jeffrey Walton a écrit : > >>> When you see a name like "example.com" in the CN, its usually a CA >>> including a domain name and not a hostname. >> >> That's nonsense. > > If a certificate is issued under CA/B policies, and CN=example.com but >

Re: [openssl-users] More on cert serialnumbers

> Le 18 août 2017 à 15:18, Mark H. Wood <mw...@iupui.edu> a écrit : > > On Thu, Aug 17, 2017 at 03:29:56PM +, Erwann Abalea via openssl-users > wrote: >> The BR are for public CAs, not private CAs; even if some of those >> requirements are considered « go

Re: [openssl-users] Doubt regarding O-SSL and setting the duration of certificates

> Le 13 sept. 2017 à 17:08, Michael Wojcik a > écrit : > >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf >> Of Michael Richardson >> Sent: Wednesday, September 13, 2017 09:32 >> >> I suspect that the value: literal value

Re: [openssl-users] Using set_serial to control serial number size directly

My proposal. Keep k bits (k/8 octets) long serial numbers for all your certificates, chose a block cipher operating on blocks of k bits, and operate this block cipher in CTR mode, with a proper secret key and secret starting counter. That way, no collision detection is necessary, you’ll be

Re: [openssl-users] Path Length Constraint ignored for Root and any self-issued certificate

Bonjour, The prospective certification path excludes the Trust Anchor. Therefore, the « max_path_length=0 » step is attained only when dealing with your EvilCA cert. Cordialement, Erwann Abalea > Le 8 oct. 2018 à 14:47, Peter Magnusson a > écrit : > > That is not correct behaviour as far as

Re: [openssl-users] RSA Public Key error

Bonjour, Assuming the first 24 bytes you’re talking about are the very beginning of the SPKI structure (that is, the enclosing SEQUENCE, and the AlgorithmIdentifier), that means you’ve replaced up to the first byte of the BITSTRING containing the public key (this byte indicates the number of

Re: [openssl-users] RSA Public Key error

om 16 byte information after removing the originally present first 24 bytes)? That is the only keyfile received by us. Thanks and Regards, Prithiraj On Wed, 12 Dec 2018 at 12:32, Erwann Abalea via openssl-users mailto:openssl-users@openssl.org>> wrote: Bonjour, Assuming the first 24 byte

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Bonjour, Here, reject the certificate is the correct behaviour, IMO. UTCTime/GeneralizedTime are defined in X.680. UTCTime: - can have no timezone information, or have Z, of have a timezone offset (with hours and minutes) - can be precise up to the second, or be precise up to the minute -

Re: Why were edwards curves given distinct key types, aren't they EC keys?

Maybe because EVP_PKEY_EC designates an ECDSA key, that an EdDSA key is not generated the same way (particularly the public part), and that the encodings are different? Cordialement, Erwann Abalea Le 15/03/2019 19:20, « openssl-users au nom de Sam Roberts » a écrit : It seems like they

Re: client certs with no subjectName only SAN

Bonjour, In the same paragraph, the sentence before the one you're quoting says "If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical." It's not possible to have a missing subject name in a certificate, the

Re: client certs with no subjectName only SAN

Bonjour, Having a critical extension adds 3 octets (the BOOLEAN tag, length=1, value=0xff). It may, as a side effect, enlarge the number of octets necessary to encode some structure size. Remove the 2 Netscape extensions, they're way obsolete (don't know why OpenSSL keeps them by default).

Re: [EXTERNAL] Re: odd error for ECDSA key in REQ.

The key itself is good. Its encoding in the CSR isn't. Looks like the public key was X9.62 encoded in its uncompressed form (i.e. start with a 04 octet, and then the octets composing the x and y coordinates), and then wrapped into an ASN.1 OCTET STRING (i.e. use the 04 tag, plus a 0x41 length,

Re: [EXTERNAL] Re: Unusual certificates

The second certificate seems garbaged at the 4th RDN of the issuerName. The Base64 edition might have added or deleted some characters. Cordialement, Erwann Abalea Le 25/06/2020 16:00, « openssl-users au nom de Angus Robertson - Magenta Systems Ltd » a écrit : More information, the

Re: [EXTERNAL] Keytool issue with version 3.0.2.

Bonjour, OpenSSL 3 changed the default ciphers used to protect the private keys and certificates when creating a PKCS#12, to use something less aging. Try adding a "-legacy" when creating the PKCS#12 file with OpenSSL3 and see if keytool can read it. On Thu, May 19, 2022 at 11:53 AM Djordje

Re: [EXTERNAL] Using openssl-rsautl for verifying signatures.

Bonjour, The ASN.1 structure (it's a DigestInfo) is part of the PKCS#1 v1.5 padding for signature operations. PKCS#1v1.5 is rewritten in RFC2313. Using the command line tool, you can reproduce this: echo -n "Mary had a little lamb." > datatosign either one of the following can be used to sign

Re: [EXTERNAL] Stricter pathlen checks in OpenSSL 1.1.1 compared to 1.0.2?.

Assuming that all self-signed certificates are trusted (here, A and B), then providing a CAfile with D+C+B+A to validate E, the different possible paths are: - E <- D <- B: this path is valid - E <- D <- C <- A: this path is valid In the validation algorithm described in RFC5280 and X.509, the