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

Missing Docs for cert.pem, chain.pem, fullchain.pem, etc #608

Closed
coolaj86 opened this Issue Jul 13, 2015 · 8 comments

Comments

Projects
None yet
7 participants
@coolaj86
Contributor

coolaj86 commented Jul 13, 2015

When this goes live, where will the intermediate certificates be located?

Searching the docs for chain.pem yields no results.

I just [asked on the mailing list](See https://groups.google.com/a/letsencrypt.org/forum/#!topic/client-dev/jE5uK4lPx5g), but it seems it should be an issue on here as well.

Currently we have these files:

  • privkey.pem
  • cert.pem
  • chain.pem
  • fullchain.pem

But we don't know what goes in them. With the current dummy certificate it puts the Root CA in the chain.pem (which seems wrong) and fullchain.pem and that the Server Certificate goes into cert.pem and fullchain.pem, but we don't know where the Intermediate Certificates go.

This is extremely important because some webservers are lax, others are strict, others barf if you give too much info, others silently fail if you give to little.

I've already written some documentation and demo code based on assumption, but I already know that that's going to blow up in my face if I don't get the details correct.

In order for greatest compatibility with various servers it would seem that we need a file that bundles the server + intermediate certificates, and excludes the root certificate. I'm hoping that's what cert.pem is intended to be.

Once I know the technical details as to what these files are supposed to represent, I may open another issue to discuss the need for additional files.

@coolaj86

This comment has been minimized.

Show comment
Hide comment
@coolaj86

coolaj86 Jul 13, 2015

Contributor

Peter E. writes

At the moment we don't have any intermediate chains deployed on our test systems. When those exist (for launch) they will be present in chain.pem and fullchain.pem, and should take the place of the root that's currently in those files. At that stage, if you want to get a copy of the Let's Encrypt root, that would be an out of band operation (or could be a separate command line flag).

See https://groups.google.com/a/letsencrypt.org/d/msg/client-dev/jE5uK4lPx5g/mbufIV-2OMYJ

  • privkey.pem - private key
  • cert.pem - server cert only
  • chain.pem - intermediates
  • fullchain.pem - server cert + intermediates
  • root.pem - proposed for root only (via optional argument)
Contributor

coolaj86 commented Jul 13, 2015

Peter E. writes

At the moment we don't have any intermediate chains deployed on our test systems. When those exist (for launch) they will be present in chain.pem and fullchain.pem, and should take the place of the root that's currently in those files. At that stage, if you want to get a copy of the Let's Encrypt root, that would be an out of band operation (or could be a separate command line flag).

See https://groups.google.com/a/letsencrypt.org/d/msg/client-dev/jE5uK4lPx5g/mbufIV-2OMYJ

  • privkey.pem - private key
  • cert.pem - server cert only
  • chain.pem - intermediates
  • fullchain.pem - server cert + intermediates
  • root.pem - proposed for root only (via optional argument)
@asquelt

This comment has been minimized.

Show comment
Hide comment
@asquelt

asquelt Aug 19, 2015

i'd propose combined.pem as sum of privkey.pem and fullchain.pem. haproxy reverse proxy requires this format, stunnel also accepts it.

https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.1-crt

asquelt commented Aug 19, 2015

i'd propose combined.pem as sum of privkey.pem and fullchain.pem. haproxy reverse proxy requires this format, stunnel also accepts it.

https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.1-crt

@coolaj86

This comment has been minimized.

Show comment
Hide comment
@coolaj86

coolaj86 Aug 20, 2015

Contributor

+1

I just set this up in haproxy myself yesterday.

cat cert.pem chain.pem privkey.pem > combined.pem
Contributor

coolaj86 commented Aug 20, 2015

+1

I just set this up in haproxy myself yesterday.

cat cert.pem chain.pem privkey.pem > combined.pem
@jdkasten

This comment has been minimized.

Show comment
Hide comment
@jdkasten

jdkasten Sep 11, 2015

Contributor

I think this may being taken care of starting with #762 (multi-step process)

Contributor

jdkasten commented Sep 11, 2015

I think this may being taken care of starting with #762 (multi-step process)

@bmw bmw added area: documentation and removed bug labels Oct 16, 2015

@bmw bmw added this to the 1.0 for launch milestone Oct 16, 2015

@bmw bmw unassigned schoen Oct 16, 2015

@kuba

This comment has been minimized.

Show comment
Hide comment
@kuba

kuba Oct 20, 2015

Contributor

We should also document that people should use stuff from /etc/letsencrypt/live rather than going to any other directory (e.g. /etc/letsencrypt/keys or /etc/letsencrypt/archive).

Contributor

kuba commented Oct 20, 2015

We should also document that people should use stuff from /etc/letsencrypt/live rather than going to any other directory (e.g. /etc/letsencrypt/keys or /etc/letsencrypt/archive).

@pde

This comment has been minimized.

Show comment
Hide comment
@pde

pde Oct 22, 2015

Member

Perhaps we should have storage.py write a README.txt file with all of those files; it can explain which ones to use with which directives in common server software.

Then we can tweak cli._report_new_cert to point the user at the directory with the README.

Member

pde commented Oct 22, 2015

Perhaps we should have storage.py write a README.txt file with all of those files; it can explain which ones to use with which directives in common server software.

Then we can tweak cli._report_new_cert to point the user at the directory with the README.

@coolaj86

This comment has been minimized.

Show comment
Hide comment
@coolaj86

coolaj86 Oct 22, 2015

Contributor

The names should be standardized across clients, not just for python. The last thing in the world I want is a new standard that is too pansy too actually define a standard.

Remember the OAuth2 debacle? Where EVERYTHING is vender specific and no two implementations are actually compatible? TERRIBLE experiences. Hours upon hours of wasted time and lines upon lines of wasted code.

Let's bring it right to the homepage of letsencrypt.org and make sure it sticks.

Contributor

coolaj86 commented Oct 22, 2015

The names should be standardized across clients, not just for python. The last thing in the world I want is a new standard that is too pansy too actually define a standard.

Remember the OAuth2 debacle? Where EVERYTHING is vender specific and no two implementations are actually compatible? TERRIBLE experiences. Hours upon hours of wasted time and lines upon lines of wasted code.

Let's bring it right to the homepage of letsencrypt.org and make sure it sticks.

@coolaj86

This comment has been minimized.

Show comment
Hide comment
@coolaj86

coolaj86 Oct 22, 2015

Contributor

Put some language in the RFC "MUST be exported to PEM plaintext as fullchain.pem ..." and later "clients SHOULD allow export names to be configured". That way the standard is clear, but people that are boneheads and have to do everything "their way" just to gratify their own programmer arrogance and pride (like myself, for example), can still configure it to be some other confusing name if they want to.

And that's the whole Zen of python anyway right? Tell 'em how it's gonna be, but put configuration over convention to avoid confusion and allow user choice.

Contributor

coolaj86 commented Oct 22, 2015

Put some language in the RFC "MUST be exported to PEM plaintext as fullchain.pem ..." and later "clients SHOULD allow export names to be configured". That way the standard is clear, but people that are boneheads and have to do everything "their way" just to gratify their own programmer arrogance and pride (like myself, for example), can still configure it to be some other confusing name if they want to.

And that's the whole Zen of python anyway right? Tell 'em how it's gonna be, but put configuration over convention to avoid confusion and allow user choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment