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

fix path to SUSE CA bundle #884

Closed
wants to merge 2 commits into
base: trunk
from

Conversation

Projects
None yet
2 participants
@mcalmer
Contributor

mcalmer commented Oct 3, 2016

Changes Title (replace this with a logical title for your changes)

Description

Fix the path to the SUSE CA bundle. The old path is a special CA file and not the CA bundle.

Status

  • done, ready for review
@tonybaloney

This comment has been minimized.

Show comment
Hide comment
@tonybaloney

tonybaloney Oct 4, 2016

Contributor

@mcalmer this path was used based on a live instance of suse and testing an issue with a consumer (salt) - see related issue saltstack/salt#32743

Are there any differences with the files?

Contributor

tonybaloney commented Oct 4, 2016

@mcalmer this path was used based on a live instance of suse and testing an issue with a consumer (salt) - see related issue saltstack/salt#32743

Are there any differences with the files?

@mcalmer

This comment has been minimized.

Show comment
Hide comment
@mcalmer

mcalmer Oct 4, 2016

Contributor

SUSE bring a yast module called yast2 ca_mgm to create own CA certificates and sign certificates.
You can import such a certificate including the CA. In this case the CA certificate is stored with the name /etc/ssl/certs/YaST-CA.pem in SLES11. This does not apply anymore with SLES12 and current openSUSE distributions.

This file contains only 1 certificate and is not a bundle. Older SLES never used bundles. We used openssl directory structure. Every file contain only one certificate.
With current SLES and openSUSE, we introduce a pki structure to generate any kind of trust stores. This include also a ca-bundle with the path I added with this commit. In case a CA is imported the ca-bundle contain also the certificate which was called YaST-CA.pem in the past.

Of cause in SLES11 there is still a problem. But including a single CA is only a workaround which will help only in a few cases.

Contributor

mcalmer commented Oct 4, 2016

SUSE bring a yast module called yast2 ca_mgm to create own CA certificates and sign certificates.
You can import such a certificate including the CA. In this case the CA certificate is stored with the name /etc/ssl/certs/YaST-CA.pem in SLES11. This does not apply anymore with SLES12 and current openSUSE distributions.

This file contains only 1 certificate and is not a bundle. Older SLES never used bundles. We used openssl directory structure. Every file contain only one certificate.
With current SLES and openSUSE, we introduce a pki structure to generate any kind of trust stores. This include also a ca-bundle with the path I added with this commit. In case a CA is imported the ca-bundle contain also the certificate which was called YaST-CA.pem in the past.

Of cause in SLES11 there is still a problem. But including a single CA is only a workaround which will help only in a few cases.

@tonybaloney

This comment has been minimized.

Show comment
Hide comment
@tonybaloney

tonybaloney Oct 4, 2016

Contributor

The path list is a collection so you can add both and we can cover 12 and 11 cases? They are done in sequence so put the newer one first

    _____________________________

From: Michael Calmer notifications@github.com
Sent: Tuesday, October 4, 2016 6:31 pm
Subject: Re: [apache/libcloud] fix path to SUSE CA bundle (#884)
To: apache/libcloud libcloud@noreply.github.com
Cc: Comment comment@noreply.github.com, Anthony Shaw anthony.p.shaw@gmail.com

SUSE bring a yast module called yast2 ca_mgm to create own CA certificates and sign certificates.
You can import such a certificate including the CA. In this case the CA certificate is stored with the name /etc/ssl/certs/YaST-CA.pem in SLES11. This does not apply anymore with SLES12 and current openSUSE distributions.

This file contains only 1 certificate and is not a bundle. Older SLES never used bundles. We used openssl directory structure. Every file contain only one certificate.
With current SLES and openSUSE, we introduce a pki structure to generate any kind of trust stores. This include also a ca-bundle with the path I added with this commit. In case a CA is imported the ca-bundle contain also the certificate which was called YaST-CA.pem in the past.

Of cause in SLES11 there is still a problem. But including a single CA is only a workaround which will help only in a few cases.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Contributor

tonybaloney commented Oct 4, 2016

The path list is a collection so you can add both and we can cover 12 and 11 cases? They are done in sequence so put the newer one first

    _____________________________

From: Michael Calmer notifications@github.com
Sent: Tuesday, October 4, 2016 6:31 pm
Subject: Re: [apache/libcloud] fix path to SUSE CA bundle (#884)
To: apache/libcloud libcloud@noreply.github.com
Cc: Comment comment@noreply.github.com, Anthony Shaw anthony.p.shaw@gmail.com

SUSE bring a yast module called yast2 ca_mgm to create own CA certificates and sign certificates.
You can import such a certificate including the CA. In this case the CA certificate is stored with the name /etc/ssl/certs/YaST-CA.pem in SLES11. This does not apply anymore with SLES12 and current openSUSE distributions.

This file contains only 1 certificate and is not a bundle. Older SLES never used bundles. We used openssl directory structure. Every file contain only one certificate.
With current SLES and openSUSE, we introduce a pki structure to generate any kind of trust stores. This include also a ca-bundle with the path I added with this commit. In case a CA is imported the ca-bundle contain also the certificate which was called YaST-CA.pem in the past.

Of cause in SLES11 there is still a problem. But including a single CA is only a workaround which will help only in a few cases.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

@mcalmer

This comment has been minimized.

Show comment
Hide comment
@mcalmer

mcalmer Oct 4, 2016

Contributor

Agreed. This will at least not break older installations. I will adapt the PR.

Contributor

mcalmer commented Oct 4, 2016

Agreed. This will at least not break older installations. I will adapt the PR.

@tonybaloney

This comment has been minimized.

Show comment
Hide comment
@tonybaloney

tonybaloney Oct 4, 2016

Contributor

👍

Contributor

tonybaloney commented Oct 4, 2016

👍

@asfgit asfgit closed this in 902ff9f Oct 4, 2016

asfgit pushed a commit that referenced this pull request Oct 4, 2016

asfgit pushed a commit that referenced this pull request Oct 5, 2016

asfgit pushed a commit that referenced this pull request Oct 5, 2016

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