Hi Christina,

I ran into the same problem recently (Client Hello, RST) , as our Bluecoat Proxy doesn't like TLS1.2 much...

Pulp uses python-requests to download packages and I was able to change the behaviour there. See https://bugzilla.redhat.com/show_bug.cgi?id=1039471#c4 for the diff.

best regards,
florian

On 03/10/2014 09:56 PM, Christina Plummer wrote:

--
!!! ACHTUNG !!!
Die elektronische DKIM-Signatur die der absendende Mailserver der Nachricht beigefügt hat, ist Fehlerhaft. Es handelt sich bei dieser Mail mit großer Wahrscheinlichkeit um eine Faelschung/Spam etc. mx3-phx2.redhat.com ist nicht vertrauenswuerdig!
--

Update - after studying the packet captures, I noticed that all the failures (both Pulp2.3 and openssl s_client) were when TLS 1.2 was used. When I forced s_client to use TLS 1.0 or 1.1, the SSL handshake succeeded.

Is there a way to force Pulp to use TLS 1.0?


On Mon, Mar 10, 2014 at 4:14 PM, Christina Plummer <[email protected] <mailto:[email protected]>> wrote:

    We do go through a proxy, but authentication is not required on
    port 443. Both servers are on the same subnet.

    Pulp-2.1.3-server:
     * RHEL 6.5 x86_64
     * yum to cdn.redhat.com <http://cdn.redhat.com> works
     * curl to cdn.redhat.com <http://cdn.redhat.com> works
     * Pulp to cdn.redhat.com <http://cdn.redhat.com> works

    Pulp-2.3.1-server:
     * RHEL 6.5 x86_64
     * yum to cdn.redhat.com <http://cdn.redhat.com> works
     * curl to cdn.redhat.com <http://cdn.redhat.com> works
     * Pulp to cdn.redhat.com <http://cdn.redhat.com> fails

    (I couldn't get openssl s_client to work on either one, but I
    think that is probably user error or otherwise irrelevant)

    I did packet captures on both servers while running "pulp rpm repo
    sync run".
    On the 2.3.1 server, the SSL Client Hello does not include a
    Server Name, and is followed by a RST.
    On the 2.1.3 server, the SSL Client Hello includes a Server Name
    of cdn.redhat.com <http://cdn.redhat.com>, and is followed by a
    SSL Server Hello and the rest of the process proceeds as expected.

    So... why is the 2.3.1 not sending a Server Name is its SSL Client
    Hello?

    Thanks,
    Christina



    On Sat, Mar 8, 2014 at 12:54 AM, Steven Roberts
    <[email protected] <mailto:[email protected]>> wrote:

        I sort of recall having a similar cert issue around the same
        time I
        upgraded to 2.3 but we had two external issues:
        - our accounting group decided to change our RH account so we
        had to get
          new entitlement certs
        - a proxy had been added to out outbound connection causing a
        server
          cert issue.

        are you behind a proxy?  thinking maybe doing a 'openssl s_client'
        to get the cert to confirm it is the one you are expecting...

        that socket reset sounds like one side isn't liking the SSL
        negotiation which could be a client or server issue.

        I would check the ssl side of things, you could also
        tcpdump/tshark
        the connection to see if one side is raising an ssl error...

        Steve

        On Fri, Mar 07, 2014 at 09:00:51PM -0500, Christina Plummer wrote:
        > Hi Steve,
        > Both the 2.1 and 2.3 Pulp servers are running RHEL 6.5.
        >
        > Thanks,
        > Christina
        >
        > Sent from mobile
        >
        > > On Mar 7, 2014, at 8:28 PM, Steven Roberts
        <[email protected] <mailto:[email protected]>> wrote:
        > >
        > > what os,arch are you running your pulp server on?
        > >
        > > I am on a RHEL 6 (64bit) box with pulp 2.3.1-1 package and
        my sync's
        > > of RH CDN are working.
        > >
        > > I have feed-cert and feed-key (both set to the same .pem I
        downloaded
        > > from RH using the instructions in the pulp guide).
        > >
        > > I did just look and I am setting the feed-ca-cert to a
        redhat-uep.pem
        > > (and I also have skipping of DRPMS as we don't use them in
        our env)
        > >
        > > Steve
        > >
        > >> On Fri, Mar 07, 2014 at 04:50:21PM -0500, Christina
        Plummer wrote:
        > >> Update - I was able to use curl to download the
        repomd.xml file that Pulp
        > >> seems to be choking on.  So I am definitely thinking this
        is a Pulp 2.3
        > >> problem.
        > >>
        > >> This worked:
        > >> sudo curl -v
        > >>
        
https://cdn.redhat.com/content/dist/rhel/server/6/6Server/x86_64/os/repodata/repomd.xml--cacert
        > >> /etc/rhsm/ca/redhat-uep.pem --cert
        > >> /etc/pki/entitlement/1545770057920900266.pem --key
        > >> /etc/pki/entitlement/1545770057920900266-key.pem
        > >>
        > >>
        > >>
        > >>
        > >> On Fri, Mar 7, 2014 at 4:02 PM, Christina Plummer
        <[email protected] <mailto:[email protected]>>wrote:
        > >>
        > >>> I've been working with Pulp 2.1.3 for several months,
        and decided that I
        > >>> wanted to get 2.3.1 stood up on a new server and migrate
        over to it.
        > >>> Unfortunately, I have not been able to get Pulp 2.3.1 to
        sync from the Red
        > >>> Hat channels.  Here is the error I get:
        > >>> Downloading metadata...
        > >>> [\]
        > >>> ... failed
        > >>>
        > >>> HTTPSConnectionPool(host='cdn.redhat.com
        <http://cdn.redhat.com>', port=443): Max retries
        > >>> exceeded with
        > >>> url:
        /content/dist/rhel/server/6/6Server/x86_64/os/repodata/repomd.xml
        > >>> (Caused
        > >>> by <class 'socket.error'>: [Errno 104] Connection reset
        by peer)
        > >>>
        > >>> I don't believe I have a network or
        subscription/entitlement issue,
        > >>> because I am able to use yum to update packages from
        cdn.redhat.com <http://cdn.redhat.com>.  I
        > >>> set up my Pulp 2.3.1 repos in the same way as I have
        them on my 2.1.3
        > >>> server, e.g.
        > >>>
        > >>> sudo pulp-admin rpm repo create --repo-id=live-rhel6-x86_64
        > >>> --description="RHEL6 x86_64 Latest"
        > >>> --feed-cert=/etc/pki/entitlement/1545770057920900266.pem
        > >>>
        --feed-key=/etc/pki/entitlement/1545770057920900266-key.pem
        
--feed=https://cdn.redhat.com/content/dist/rhel/server/6/6Server/x86_64/os
        > >>>
        
--retain-old-count=1<https://cdn.redhat.com/content/dist/rhel/server/6/6Server/x86_64/os--retain-old-count=1>--validate=true
        --relative-url=rhel6/x86_64 --serve-http=true
        > >>> --serve-https=false
        > >>> --gpg-key=/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-legacy-release
        > >>> I am still able to sync from RHN to my Pulp 2.1.3
        server, so there doesn't
        > >>> seem to be an issue with Red Hat itself.
        > >>>
        > >>> It seems like an SSL error, but I can't figure out what
        it would be... I
        > >>> tried adding --feed-ca-cert=/etc/rhsm/ca/redhat-uep.pem,
        but that didn't
        > >>> seem to have any effect (and hasn't been needed on my
        2.1.3 server).
        > >>>
        > >>> Any ideas?  Has anyone else got syncing from
        cdn.redhat.com <http://cdn.redhat.com> working on
        > >>> Pulp 2.3.1?
        > >>>
        > >>> Thanks,
        > >>> Christina
        > >
        > >> _______________________________________________
        > >> Pulp-list mailing list
        > >> [email protected] <mailto:[email protected]>
        > >> https://www.redhat.com/mailman/listinfo/pulp-list
        > >
        >





_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list

--
Florian Sachs
Bundesministerium für Landesverteidigung und Sport
Führungsunterstützungszentrum / IKT-Te / HW&SysSW / SE2VE
Stiftgasse 2a 1070, Wien
Postadresse: Rossauer Lände 1, 1090 Wien
Tel.: +43 50201 10 33466

_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list

Reply via email to