action #37644
closed[tools] osd SSL certificate is only valid for openqa.suse.de, not for openqa.nue.suse.com
Added by okurz almost 6 years ago. Updated 3 months ago.
0%
Updated by coolo over 5 years ago
- Project changed from openQA Tests to openQA Infrastructure
- Category deleted (
Infrastructure)
Updated by nicksinger over 5 years ago
- Status changed from New to In Progress
I've created the CSR and sent it to infra to sign it:
Hey Guys,
attached is the new CSR for openqa.suse.de. It now also includes
openqa.nue.suse.com (as requested in
https://progress.opensuse.org/issues/37644).
Is it possible to sign this request without invalidating/revoking the
old certificate of openqa.suse.de? I'd like to do a smooth rollover there.
Thanks in advance,
Nick
https://infra.nue.suse.com/SelfService/Display.html?id=123024
Waiting for the cert now.
Updated by nicksinger over 5 years ago
- Status changed from In Progress to Feedback
Updated by nicksinger over 5 years ago
Ah, forgot to mirror my update from the infra-ticket-system here:
Got the cert, SAN is missing from it (got stripped most likely). Reopened the infra-ticket with the initial request but since it's assigned to fatma (and she is out-of-office) seems like nobody else cares about it.
Maybe with the next deployment then… I'll keep you posted
Updated by okurz over 4 years ago
nicksinger wrote:
[…]
Maybe with the next deployment then… I'll keep you posted
next thing you tell me the cake is not a lie as well ;)
Updated by nicksinger over 4 years ago
- Copied to action #58676: [tools] manage certificates by salt (pillars) added
Updated by okurz about 4 years ago
As discussed in https://chat.suse.de/group/openqa-dev?msg=3XsRNd5nFtTRBpdsJ
We want to manage the complete system configuration in salt hence also certs need to be covered. I suggest to pick whatever is the most easy option frist, everything else as potential improvement for later, i.e. store key in plain text, later optionally look into encrypted pillars, e.g. encrypting the pillars with a password encrypted with (tools-team) employees gpg-key.
Updated by okurz about 4 years ago
- Status changed from Feedback to Resolved
Fixed! https://openqa.nue.suse.com/ reports as secure now :) See #58676 for details
Updated by okurz about 4 years ago
- Status changed from Resolved to Feedback
- Priority changed from Normal to Urgent
Multiple users reported problems. Despite firefox showing that everything is in order and I assume it correctly uses ca-certificates-suse e.g. also curl https://openqa.suse.de does not accept the new certificates. I have reverted to the old certificates for now but a new salt high state might overwrite them again although I have marked the files and dir as read-only for now:
/etc/apache2/
cd ssl.crt/
cp -a openqa.suse.de.crt{,-20200303-broken}
ln -f openqa.suse.de.crt{-20200302,}cd ../ssl.key/
cp -a openqa.suse.de.key{,-20200303-broken} && ln -f openqa.suse.de.key{-20200302,}
systemctl restart apache2
cd ..
chmod -R a-w ssl.{key,crt}/
For testing I suggest the following command:
podman run --rm -it registry.suse.de/home/okurz/container/images/curl:latest sh -c 'curl -q https://openqa.suse.de -o /dev/null && curl -q https://openqa.nue.suse.com -o /dev/null'
Updated by nicksinger about 4 years ago
- Priority changed from Urgent to Normal
Firefox is somewhat special when it comes to chain checks. Since we extended the cert to also cover "openqa.nue.suse.com" now we also had to add the trust anchor for "suse.com" in our certificate chain. For this all what was needed is to extend our current chain: curl http://ca.suse.de/certificates/chain/SUSE_CA_suse.com.chain.crt >> SUSE_CA_suse.de.chain.crt (located in /etc/apache2/ssl.crt/) and reload apache afterwards.
btw: I figured this out with echo | openssl s_client -connect openqa.suse.de:443 which shows the whole chain and where it fails to validate.
I'll lower the prio but keep the ticket open until we salt the chain too. I see this task blocked by "[RT-ADM #165010] AutoReply: Certificate for ca.suse.de wrong".
Updated by livdywan about 4 years ago
Any update on this? Still blocking on getting the new cert?
Updated by nicksinger about 4 years ago
- Status changed from Feedback to Workable
- Assignee deleted (
nicksinger)
ca.suse.de got a valid SSL certificate in the meantime. Unfortunately it still uses TLS1.0 which is considered insecure by some software - so I will try to ping them once again. However, in general we could start to write this chain generation state now.
Updated by okurz almost 4 years ago
- Target version set to Ready
nicksinger wrote:
ca.suse.de got a valid SSL certificate in the meantime. Unfortunately it still uses TLS1.0 which is considered insecure by some software - so I will try to ping them once again. However, in general we could start to write this chain generation state now.
Updated by okurz 3 months ago
- Related to action #117553: multiple people can not access openqa.suse.de but can access openqa.nue.suse.com, we should clarify the difference and maybe change our wording added
Updated by okurz 3 months ago
- Status changed from Workable to Resolved
- Assignee set to okurz
- Target version changed from future to Ready
Solved with salt-states-openqa commit 9aa3c58, Author: Oliver Kurz okurz@suse.de, Date: Mon Nov 29 08:47:27 2021 +0100, Add SSL management with dehydrated