Subject: [pkix] RFC 5280 and example of a self signed end-entity certificate?

From: Jeffrey Walton <[email-masked]>
Date: Sat, 19 Nov 2016 15:35:04 -0500

RFC 5280, Appendix C, has a few examples of certificates. However, its
lacking an example of a self-signed end-entity certificate.

Does anyone know where I might find an example of a elf-signed
end-entity certificate?

Thanks in advance.

---

From: gmail <[email-masked]>
Date: Sun, 20 Nov 2016 14:53:31 +0800

many softwares has a self-signed certficate if you config so.for 
example ,filezilla server use self-signed https server certificate if 
you create one directly.

在 2016.11.20 4:35, Jeffrey Walton 写道:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 20 Nov 2016 06:56:12 +0000

Jeffrey Walton <[email-masked]> writes:

>Does anyone know where I might find an example of a elf-signed end-entity
>certificate?

By finding an elf and getting them to sign one for you?  Alternatively, if you
want a *self*-signed EE cert, by signing one yourself?  Or am I missing
something here...

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 20 Nov 2016 09:06:51 +0200

> On 20 Nov 2016, at 8:56, Peter Gutmann <[email-masked]> wrote:
> 
> something here…

I think you’re missing this:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes

You can even skip the “-keyout key.pem” if you only need an example cert.  And you can add a "-outform DER" if you prefer it that way.

Yoav

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 20 Nov 2016 03:05:28 -0500

> want a *self*-signed EE cert, by signing one yourself?  Or am I missing

My bad. I wanted an IETF reference one; not a random one crated by an
external tool.

Jeff

---

From: Yoav Nir <[email-masked]>
Date: Sun, 20 Nov 2016 12:28:34 +0200

> On 20 Nov 2016, at 10:05, Jeffrey Walton <[email-masked]> wrote:
> 

Well, you generate one with an external tool; then you copy the result into an Internet Draft, and then you have an IETF reference one…

Of course you can perform all the calculations yourself and hand-encode the DER, but that looks too hard and error-prone to me.

Yoav

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 24 Nov 2016 17:56:50 -0500

> openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365

Forgive m if I am wrong... That creates a malformed server certificate
because the hostname is placed in the CN and not the SAN, it uses SHA1
by default, and it fails to use UTF-8 strings by default. At minimum,
its not following best practices and using deprecated methods.

I'm also interested in seeing  what an "ideal" or "minimal" client
certificate should look like. Especially how a principal name, like
"jdoe" (used as a corporate login), should appear since its probably
distinct from the Subject DN.

Jeff

---

From: Annie <[email-masked]>
Date: Fri, 25 Nov 2016 08:23:05 +0100

Jeff,
the command
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -nodes

creates not an *EE* certificate but a CA certificate (cA is TRUE).
An EE-certificate has by definition not other certs below, it is a leaf
of the certification path. Therefore in the basicContraints field cA
must be set to FALSE.

E.g.
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

Check it with the OpenSSL command
openssl verify -CAfile cert.pem cert.pem

Nevertheless I'm not sure that this is correct because the cert is not a
*CAfile*.

Regards,
/Ann.

The SHA-1 issue could be solved easier: add the option -sha256.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 25 Nov 2016 08:06:36 +0000

Jeffrey Walton <[email-masked]> writes:

>That creates a malformed server certificate because the hostname is placed in
>the CN and not the SAN, it uses SHA1 by default, and it fails to use UTF-8
>strings by default. At minimum, its not following best practices and using
>deprecated methods.

It depends on what you define as "malformed".  Everything puts the server name
in the DN, you don't need UTF-8 strings in most cases, and whether you use
SHA-1 in a self-signed EE cert is a matter of preference (it's not like
someone is going to have to break SHA-1 to create a fake cert)...

Peter.