[opensuse-buildservice] OBS 1.3 Privately signed certificate and osc

Dominig ar Foll (Intel OTC)

4 Apr 2012 4 Apr '12

14:19

Hello, having just updated to OBS 1.3, my API is now running under https (not a bad idea). I have created a PRIVATE certificate following the README. --------------- mkdir /srv/obs/certs openssl genrsa -out /srv/obs/certs/server.key 1024 openssl req -new -key /srv/obs/certs/server.key \ -out /srv/obs/certs/server.csr openssl x509 -req -days 365 -in /srv/obs/certs/server.csr \ -signkey /srv/obs/certs/server.key -out /srv/obs/certs/server.crt cat /srv/obs/certs/server.key /srv/obs/certs/server.crt \ > /srv/obs/certs/server.pem ---------------------- I see that with osc (version 0.134.1) if the privately signed certificate is create with a Common Name (CN) which is not the server name, osc refuses to chat with the API. That is bit strick as : - CN name is normally free of use - In that mode access via IP address is not possible any more - auto recovery system with shadow server configuration cannot be done. That is very strange as it seems that when the certificate with an official root, the common name is not critical. Any clue how to overcome that issue ? Regards -- Dominig -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Show replies by date

Dominig ar Foll (Intel OTC)

4 Apr 4 Apr

14:25

New subject: [opensuse-buildservice] Re: OBS 2.3 Privately signed certificate and osc

Oups not 1.3 but 2.3 Le 04/04/2012 16:19, Dominig ar Foll (Intel OTC) a écrit :

...

Hello,

having just updated to OBS 2.3, my API is now running under https (not a bad idea). I have created a PRIVATE certificate following the README. ---------------

mkdir /srv/obs/certs openssl genrsa -out /srv/obs/certs/server.key 1024 openssl req -new -key /srv/obs/certs/server.key \ -out /srv/obs/certs/server.csr openssl x509 -req -days 365 -in /srv/obs/certs/server.csr \ -signkey /srv/obs/certs/server.key -out /srv/obs/certs/server.crt cat /srv/obs/certs/server.key /srv/obs/certs/server.crt \ > /srv/obs/certs/server.pem

---------------------- I see that with osc (version 0.134.1)

if the privately signed certificate is create with a Common Name (CN) which is not the server name, osc refuses to chat with the API. That is bit strick as :

- CN name is normally free of use - In that mode access via IP address is not possible any more - auto recovery system with shadow server configuration cannot be done.

That is very strange as it seems that when the certificate with an official root, the common name is not critical.

Any clue how to overcome that issue ?

Regards

-- Dominig

-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

686f6c6d

18 Apr 18 Apr

20:51

On Wed, Apr 4, 2012 at 16:19, Dominig ar Foll (Intel OTC) wrote:

...

Hello,

having just updated to OBS 1.3, my API is now running under https (not a bad idea). I have created a PRIVATE certificate following the README. [...] ---------------------- I see that with osc (version 0.134.1)

if the privately signed certificate is create with a Common Name (CN) which is not the server name, osc refuses to chat with the API. [...]

That is very strange as it seems that when the certificate with an official root, the common name is not critical.

Any clue how to overcome that issue ?

I haven't looked into this recently, but I think the problem sits deeper and has nothing to do with the CN, but with the fact that the CA of your selfsigned certificate is untrusted. AFAIK osc uses m2crypto for SSL and in theory m2crypto can be told to trust your CA (that's what the internet says, at least), but I was unable to find out (from the m2crypto docs and code and the osc code): a) what dotfile I have to create for m2crypto; b) what data and format exactly has to go into there; c) if osc supports this as-is. Given the fact that creating a selfsigned certificate is part of README.SETUP, I strongly agree that this should be documented and/or fixed. AFAICT, the docs as they're now are only useful if you avoid SSL altogether or have a trusted CA. -- Kind regards 686f6c6d / Christopher 'm4z' Holm -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Bernhard M. Wiedemann

19 Apr 19 Apr

04:51

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 18.04.2012 22:51, schrieb 686f6c6d:

...

On Wed, Apr 4, 2012 at 16:19, Dominig ar Foll (Intel OTC) wrote:

...
Hello,

having just updated to OBS 1.3, my API is now running under https (not a bad idea). I have created a PRIVATE certificate following the README. [...] ---------------------- I see that with osc (version 0.134.1)

if the privately signed certificate is create with a Common Name (CN) which is not the server name, osc refuses to chat with the API. [...]

That is very strange as it seems that when the certificate with an official root, the common name is not critical.

Any clue how to overcome that issue ?

I haven't looked into this recently, but I think the problem sits deeper and has nothing to do with the CN, but with the fact that the CA of your selfsigned certificate is untrusted. AFAIK osc uses m2crypto for SSL and in theory m2crypto can be told to trust your CA (that's what the internet says, at least), but I was unable to find out (from the m2crypto docs and code and the osc code): a) what dotfile I have to create for m2crypto; b) what data and format exactly has to go into there; c) if osc supports this as-is.

Given the fact that creating a selfsigned certificate is part of README.SETUP, I strongly agree that this should be documented and/or fixed. AFAICT, the docs as they're now are only useful if you avoid SSL altogether or have a trusted CA.

I would guess, that m2crypto uses the system's CA storage in /etc/ssl/certs/ so you could do with your private CA the equivalent of zypper install ca-certificates-cacert I agree, this should be part of the documentation Ciao Bernhard M. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+PmcQACgkQSTYLOx37oWTyMQCg5oTHTJ7kB/PAD1KsA1dh/t8K TZIAnRRKhINSgC+26Jc+C2mJW+M6xhYe =fSOk -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Marcus Meissner

06:23

On Wed, Apr 18, 2012 at 10:51:47PM +0200, 686f6c6d wrote:

...

On Wed, Apr 4, 2012 at 16:19, Dominig ar Foll (Intel OTC) wrote:

...
Hello,

having just updated to OBS 1.3, my API is now running under https (not a bad idea). I have created a PRIVATE certificate following the README. [...] ---------------------- I see that with osc (version 0.134.1)

if the privately signed certificate is create with a Common Name (CN) which is not the server name, osc refuses to chat with the API. [...]

That is very strange as it seems that when the certificate with an official root, the common name is not critical.

Any clue how to overcome that issue ?

I haven't looked into this recently, but I think the problem sits deeper and has nothing to do with the CN, but with the fact that the CA of your selfsigned certificate is untrusted. AFAIK osc uses m2crypto for SSL and in theory m2crypto can be told to trust your CA (that's what the internet says, at least), but I was unable to find out (from the m2crypto docs and code and the osc code): a) what dotfile I have to create for m2crypto; b) what data and format exactly has to go into there; c) if osc supports this as-is.

Given the fact that creating a selfsigned certificate is part of README.SETUP, I strongly agree that this should be documented and/or fixed. AFAICT, the docs as they're now are only useful if you avoid SSL altogether or have a trusted CA.

osc asks to store such a certificate in its local cert store when it is not signed by any of the known root-CAs. However it needs to fulfil some basic requirements like a matching hostname ;) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

Adrian Schröter

08:08

Am Mittwoch, 18. April 2012, 22:51:47 schrieb 686f6c6d: ...

...

Given the fact that creating a selfsigned certificate is part of README.SETUP, I strongly agree that this should be documented and/or fixed. AFAICT, the docs as they're now are only useful if you avoid SSL altogether or have a trusted CA.

since osc and web browsers usually do store the initial CA it is still usefull to detect attacks later. I think an explenation how to create official CA's is too much for our doku, but we could add a link how to proceed on that. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

686f6c6d

22 Apr 22 Apr

00:42

On Thu, Apr 19, 2012 at 08:23, Marcus Meissner wrote:

...

osc asks to store such a certificate in its local cert store when it is not signed by any of the known root-CAs.

Ah, thank you very much! With a reasonably current version of osc (verified with 0.132.5 and 0.134.1) this works indeed (the certificate will be stored in ~/.config/osc/trusted-certs/${hostname}_${port}.pem). When I last tested this back around December, osc just tracebacked on me and I had to look into the m2crypto error message to find out that the communication failed because the certificate was untrusted (although I'm unsure what the precise SSL error was).

...

However it needs to fulfil some basic requirements like a matching hostname ;)

Yes that's true, my point was it failed *before* the hostname check for me, and I assumed it was still unfixed. Should have checked first, but I don't set up new OBSs that often. (; On Thu, Apr 19, 2012 at 10:08, Adrian Schröter wrote:

...

Am Mittwoch, 18. April 2012, 22:51:47 schrieb 686f6c6d:

...
Given the fact that creating a selfsigned certificate is part of README.SETUP, I strongly agree that this should be documented and/or fixed. AFAICT, the docs as they're now are only useful if you avoid SSL altogether or have a trusted CA.

since osc and web browsers usually do store the initial CA it is still usefull to detect attacks later.

I think an explenation how to create official CA's is too much for our doku, but we could add a link how to proceed on that.

Sorry, I didn't make myself clear. What I meant was that it should be possible to use osc with a selfsigned certificate, which obviously works now. (A documentation pointer on how to get m2crypto or the whole oS to trust the certificate would be nice, but isn't what I meant. I just wanted osc to work for the newbie -- me -- that installs from the official docs.) -- Kind regards 686f6c6d / Christopher 'm4z' Holm -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

686f6c6d

19 Jun 19 Jun

14:11

On Sun, Apr 22, 2012 at 2:42 AM, 686f6c6d <686f6c6d@googlemail.com> wrote:

...

On Thu, Apr 19, 2012 at 08:23, Marcus Meissner wrote:

...
osc asks to store such a certificate in its local cert store when it is not signed by any of the known root-CAs.

Ah, thank you very much! With a reasonably current version of osc (verified with 0.132.5 and 0.134.1) this works indeed (the certificate will be stored in ~/.config/osc/trusted-certs/${hostname}_${port}.pem). When I last tested this back around December, osc just tracebacked on me and I had to look into the m2crypto error message to find out that the communication failed because the certificate was untrusted (although I'm unsure what the precise SSL error was).

...
However it needs to fulfil some basic requirements like a matching hostname ;)

Yes that's true, my point was it failed *before* the hostname check for me, and I assumed it was still unfixed. Should have checked first, but I don't set up new OBSs that often. (;

On Thu, Apr 19, 2012 at 10:08, Adrian Schröter wrote:

...
Am Mittwoch, 18. April 2012, 22:51:47 schrieb 686f6c6d:

...
Given the fact that creating a selfsigned certificate is part of README.SETUP, I strongly agree that this should be documented and/or fixed. AFAICT, the docs as they're now are only useful if you avoid SSL altogether or have a trusted CA.

since osc and web browsers usually do store the initial CA it is still usefull to detect attacks later.

I think an explenation how to create official CA's is too much for our doku, but we could add a link how to proceed on that.

Sorry, I didn't make myself clear. What I meant was that it should be possible to use osc with a selfsigned certificate, which obviously works now. (A documentation pointer on how to get m2crypto or the whole oS to trust the certificate would be nice, but isn't what I meant. I just wanted osc to work for the newbie -- me -- that installs from the official docs.)

To follow up on this: We just had a problem where the DNS name temporarily did *not* match the reverse lookup and we were unable to change it (being pressed for time as usual) because changing the certificates of the whole shebang would have taken too long, so we decided to whip out the torture devices to make m2crypto/osc do as we please. My colleague who did the digging found the already existing, undocumented option "sslcertck" in /usr/lib/python2.7/site-packages/osc/conf.py (that file is worth a look). So, to disable m2crypto SSL verification in osc -- if you know what you are doing --, set "sslcertck = 0" in your .oscrc config file. -- Kind regards 686f6c6d / Christopher 'm4z' Holm -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

4335

Age (days ago)

4411

Last active (days ago)

List overview

Download

7 comments

5 participants

participants (5)

686f6c6d
Adrian Schröter
Bernhard M. Wiedemann
Dominig ar Foll (Intel OTC)
Marcus Meissner

[opensuse-buildservice] OBS 1.3 Privately signed certificate and osc

tags

participants (5)