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
p
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 Gav
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 d
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, a
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 origi
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).
If
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 field
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
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
- ca
g the custom 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 fir
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 un
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
> 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 1231235959Z will simply come to
>> mean "
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 able
> Le 18 août 2017 à 15:18, Mark H. Wood a écrit :
>
> On Thu, Aug 17, 2017 at 03:29:56PM +0000, Erwann Abalea via openssl-users
> wrote:
>> The BR are for public CAs, not private CAs; even if some of those
>> requirements are considered « good practice » (the 64 bit
> 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 the CN, its usually a CA
> including a domain name and not a hostn
> 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
> it _lacks_ SAN=exampl
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, else the DER
>> encod
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 CRLs
(such as OCSP res
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
>> mailto:openssl-users@openssl.org>> wrote:
>>
>>➢ So, in summary, do I need to ensure cert serial numbers are
>>unique fo
20 matches
Mail list logo
