error: The certificate chain presented is invalid.

[Palloy]

Ubuntu 14.04, Prosody 0.9.8

In the standard configuration, with "tls" in modules_enabled, and ssl pointing to localhost.key and localhost.crt,
Pidgin clients notice that "localhost" doesn't match "palloy.in" and needs Accepting.
It then works OK.

So I generated a key and signing request:
    prosodyctl cert request palloy.in
Then I went to startssl.com and had them sign "palloy.in" as XMPP server "chat.palloy.in",
and saved the returned certificate text as "palloy.in.crt".

Moved "palloy.in.crt" and "palloy.in.key" to /etc/prosody/certs/
permissions/owner/group: 0600 prosody:prosody

Edited the config file and restarted the server.
My clients were disconnected, as expected,
and when reconnected reported:

Pidgin:
    Unable to validate certificate
    The certificate for chat.palloy.in could not be validated.
    The certificate chain presented is invalid.
and no "Accept anyway" is offered.

As an attempt to check the chain (no idea if this is right):
    sudo openssl verify -verbose -purpose sslserver /etc/prosody/certs/palloy.in.crt
        /etc/prosody/certs/palloy.in.crt: C = HK, CN = chat.palloy.in, emailAddress = palloy@******
        error 20 at 0 depth lookup:unable to get local issuer certificate
which tells me something is wrong, but not what is.

What do I do next?

/etc/ssl/certs/ contains symlinks to:
    StartCom_Certification_Authority.pem
    StartCom_Certification_Authority-2.pem
    StartCom_Certification_Authority_G2.pem

[Bill McGonigle]

On 11/14/15 16:11, Palloy wrote:
> The certificate for chat.palloy.in could not be validated.
> The certificate chain presented is invalid.
> and no "Accept anyway" is offered.
>

> /etc/ssl/certs/ contains symlinks to:
> StartCom_Certification_Authority.pem
> StartCom_Certification_Authority-2.pem
> StartCom_Certification_Authority_G2.pem

You'll need to append one of those StartCom certs to palloy.in.crt and
then restart prosody (the one with the ID that chains to your cert, if
you know it - otherwise just try each separately).

The CA store on the machine with Pidgin most likely trusts StartCom and
then StartCom trusts one of its intermediate certs, which then trusts
your cert (the "chain"). They do this so that if an intermediate cert
is ever compromised they can not be stuck with nobody trusting their
main cert (which they "keep under armed guard"). When the client
connects, it needs you to give it the rest of the trust chain it doesn't
have, which is going to be your cert and the intermediate.

-Bill

--
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: bi...@bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle

[Matthew Wild]

On 14 November 2015 at 21:37, Bill McGonigle <bi...@bfccomputing.com> wrote:
> On 11/14/15 16:11, Palloy wrote:
>> The certificate for chat.palloy.in could not be validated.
>> The certificate chain presented is invalid.
>> and no "Accept anyway" is offered.
>>
>> /etc/ssl/certs/ contains symlinks to:
>> StartCom_Certification_Authority.pem
>> StartCom_Certification_Authority-2.pem
>> StartCom_Certification_Authority_G2.pem
>
> You'll need to append one of those StartCom certs to palloy.in.crt and
> then restart prosody (the one with the ID that chains to your cert, if
> you know it - otherwise just try each separately).

Right. StartCom will tell you which intermediate certificate you need
to append to yours. I'd look it up, but their site is apparently
offline for the night (?!). See
https://prosody.im/doc/certificates#certificate_chains for more info,
once you find it.

Regards,
Matthew

[Palloy]

I'm sure you're right. 
What I don't get is why start.com doesn't say anything about which intermediate certificate it used, or why it wasn't already rolled into the signed certificate.

I'm also confused as to why "openssl verify -verbose" doesn't tell me anything I need to know to start fixing it up.
Is there a "openssl print -all_chain /.../example.crt" ?

[Palloy]

Finally got it sorted.
The intermediate certificate needed is https://startssl.com/certs/sub.class1.server.ca.pem
There seems to be a step missing in the otherwise complete StartCom instructions.
This doesn't quite belong in the more generalised Prosody > Certificates instructions, but it wouldn't hurt.

[Matthew Wild]

Thanks! I've made some changes to the documentation, including
mentioning the need for intermediate certificate in the 'installing'
section. I don't think we can do much more than that, as maintaining a
list of where to find all the possible intermediate CA certificates is
not something we should probably try spending our time on :)

Regards,
Matthew

[Bill McGonigle]

On 11/16/15 07:38, Matthew Wild wrote:
> Thanks! I've made some changes to the documentation, including
> mentioning the need for intermediate certificate in the 'installing'
> section. I don't think we can do much more than that, as maintaining a
> list of where to find all the possible intermediate CA certificates is
> not something we should probably try spending our time on :)

A 'nice to have' would be adding a directive for the CA file like many
TLS servers do, so the server's certificate file can be only that. It
makes devops easier, especially, I can imagine, for a Prosody server
with many virtual hosts from the same CA. The current TLS world is that
some servers can handle the three concerns distinctly, some can handle
only key separately (Prosody, currently), some need all three in one
file, and some need them in a certain order in any of those files.
There's a bit of self-documentation value in having the directives just
asking the sysadmin, "tell us about each of your three filetypes," even
if the server just concatenates them for presentation to the SSL
library, and making TLS easier to deploy is good for the Internet. Og
course the actual documentation is welcome too - thanks!

[Matthew Wild]

On 16 November 2015 at 12:57, Bill McGonigle <bi...@bfccomputing.com> wrote:
> On 11/16/15 07:38, Matthew Wild wrote:
>> Thanks! I've made some changes to the documentation, including
>> mentioning the need for intermediate certificate in the 'installing'
>> section. I don't think we can do much more than that, as maintaining a
>> list of where to find all the possible intermediate CA certificates is
>> not something we should probably try spending our time on :)
>
>
> A 'nice to have' would be adding a directive for the CA file like many
> TLS servers do, so the server's certificate file can be only that. It
> makes devops easier, especially, I can imagine, for a Prosody server
> with many virtual hosts from the same CA. The current TLS world is that
> some servers can handle the three concerns distinctly, some can handle
> only key separately (Prosody, currently), some need all three in one
> file, and some need them in a certain order in any of those files.
> There's a bit of self-documentation value in having the directives just
> asking the sysadmin, "tell us about each of your three filetypes," even
> if the server just concatenates them for presentation to the SSL
> library, and making TLS easier to deploy is good for the Internet. Og
> course the actual documentation is welcome too - thanks!

Yep, I understand. The thing is, pretty much all we do with the
certificates is hand them to OpenSSL. The OpenSSL APIs are so complex,
there's more than one way to do anything. In our case it's OpenSSL
picking out the intermediate, there's no API in LuaSec for us to
provide it separately. Also some folks need more than one
intermediate, so you need to handle that as well anyway.

Luckily there's a lot of advancement in this area at the moment, what
with ACME/Let's Encrypt, LibreSSL and so on. I look forward to the
user experience regarding certificates improving very much over the
coming year or two.

Regards,
Matthew

[Kim Alvefur]

On 2015-11-16 14:30, Matthew Wild wrote:
> Luckily there's a lot of advancement in this area at the moment, what
> with ACME/Let's Encrypt, LibreSSL and so on. I look forward to the
> user experience regarding certificates improving very much over the
> coming year or two.

FWIW, Let's Encrypt (the client tool) produces a file called
'fullchain.pem' which has the cert and any intermediate, so works well
for Prosodys 'ssl.certificate' option.


--
Kim "Zash" Alvefur

[Thijs Alkemade]

To be clear, OpenSSL doesn’t “pick out” the intermediate it needs. Instead it

just grabs the first cert and uses it as its leaf cert and dumps the rest

directly into the handshake. Even if those certs are unrelated/duplicate/etc.

Thijs

[Matthew Wild]

On 16 November 2015 at 13:39, Thijs Alkemade <m...@thijsalkema.de> wrote:
> To be clear, OpenSSL doesn’t “pick out” the intermediate it needs. Instead
> it
> just grabs the first cert and uses it as its leaf cert and dumps the rest
> directly into the handshake. Even if those certs are
> unrelated/duplicate/etc.

That's good to know. It explains some weird stuff I've seen in the past...

Regards,
Matthew