Crawler and self-signed certificates

(Richard Dern) #1

Hello fellows,

First: thanks for this great piece of software, and thanks for making it free :slight_smile:

Next, I just have one issue: how to make the crawler parse my feed, which is on a website with self-signed certificate ?

(Jeff Atwood) #2

Which crawler are you referring to?

(Richard Dern) #3

Sorry, I should have been more explicit.

I want to embed discourse on my website. I set up everything, including the Atom feed, in Admin > Customize > Embed and put the js code on my posts pages, but as I’m using a self-signed certificate for this site host (which is obviously different from the host on which I host discourse), I have this error in my logs:

Started GET "/embed/comments?" for at 2016-01-20 23:52:55 +0000 Processing by EmbedController#comments as HTML Parameters: {"embed_url"=>""} Rendered embed/loading.html.erb within layouts/embed (0.4ms) Completed 200 OK in 8ms (Views: 1.3ms | ActiveRecord: 3.2ms) Job exception: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed

(Matt Palmer) #4

Oh, the fun of TLS…

DIscourse uses the system’s trust store when verifying certificates. The correct way to install a new trust anchor in the store is to add something like this to your app.yml configuration file:

    - file:
        path: /usr/local/share/ca-certificates/atomfeed.crt
        chmod: 0444
        contents: |
          -----BEGIN CERTIFICATE-----
          -----END CERTIFICATE-----
    - exec: /usr/sbin/update-ca-certificates

(That’s an untested, off-the-top-of-my-head example; test it somewhere unimportant before unleashing it in production)

The certificate you add can either be the self-signed certificate itself, or else a CA certificate which issued the certificate(s) you want to trust (directly, or through an intermediate CA certificate).

Installing self-signed CA for Omniauth
(Richard Dern) #5

I get the jist, but I lack of luck.

I put your snippet in my app.yml, only replacing cert content by the cert used by the feed’s website, then my CA’s cert.

I also tried the same but changing the file path to /etc/ssl/certs/.

Oh I forgot to mention, after each test I did ./launcher rebuild app.

Each time, during the build, I can see:

I, [2016-01-21T02:49:47.296440 #37] INFO -- : Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done.

But not sure if it means the cert have already been added or if it was not at all, I can’t see any error at this point. But discourse’s log keeps showing me the same error as in my second post here.

I think we’re close :slight_smile:

(Richard Dern) #6

Ok I made it to work. I placed my CA cert in /usr/local/share/ca-certificates/, works like a charm.

Thank you very much !

(Richard Dern) #7

Well, at least:

I, [2016-01-21T03:31:29.832760 #37]  INFO -- : File > /usr/local/share/ca-certificates/Athaliasoft.crt  chmod: u=r,g=r,o=r
I, [2016-01-21T03:31:29.837672 #37]  INFO -- : File > /usr/local/share/ca-certificates/  chmod: u=r,g=r,o=r
I, [2016-01-21T03:31:29.838235 #37]  INFO -- : > /usr/sbin/update-ca-certificates
I, [2016-01-21T03:31:31.407814 #37]  INFO -- : Updating certificates in /etc/ssl/certs... 2 added, 0 removed; done.

But it still have this error:

Job exception: hostname "" does not match the server certificate

(Matt Palmer) #8

That’s a whole different thing… the certificate still needs to be issued for the name you’re connecting to, otherwise it’ll never work. You may have to issue a different certificate, or access the service by a different name (one that is contained in the certificate that is being presented).

(Gerhard Schlager) #9

I recommend you buy a certificate or use a free certificate from Let’s Encrypt. It will make your life a lot easier.

(Richard Dern) #10

That’s the point, my certificate matches the domain name of the website.

(Richard Dern) #11

A certificate from an external CA ? hehe, not gonna happen :slight_smile:

(Felix Freiberger) #12

It looks like your certificate does not:

SSL Labs diagnoses the same issue:

(On a side note, your server is vulnerable to the POODLE attack. This is bad – you should fix this as soon as possible!)

I’d reconsider that – getting a proper certificate from Let’s Encrypt is easier than generating a proper self-signed certificate…

(Richard Dern) #13

Ok, thanks for pointing out the vulnerability.

But I’m confused about the cert name and the server name. Aren’t they the same ? Is it the alternative name that causes my troubles ?

And about the CA: I don’t want things to be easier, I want things MY way :slight_smile:

(Felix Freiberger) #14

I don’t know – being a user of CA-issued certificates, I never had to care :slight_smile:

(Matt Palmer) #15

The CN of a certificate is only examined if there is no subjectAltName extension. As soon as a sAN is found, CN is completely ignored. You’ll need to re-issue that cert with both names in the sAN if you want it to work for both names.

(Richard Dern) #16

Ok thanks, I’ll do that and let you know.

Thanks for your time !

(Richard Dern) #17

All right, I re-issued my cert as you suggested, now it works as intended.

And I solved the POODLE issue.

Thanks you all very much :slight_smile: