Hello, I'm running IPA on current Fedora 32, freeipa-server-4.8.9-2 and pki-server-10.9.0-0.4 Today the certificate of my IMAP server (running on Debian Buster) was automatically refreshed: ,---- | Request ID '20181003215953': | status: MONITORING | stuck: no | key pair storage: type=FILE,location='/etc/ssl/private/imap.jochen.org.key' | certificate: type=FILE,location='/etc/ssl/certs/imap.jochen.org.crt' | CA: IPA | issuer: CN=Certificate Authority,O=JOCHEN.ORG | subject: CN=imap.jochen.org,O=JOCHEN.ORG | expires: 2022-09-07 09:30:16 CEST | dns: imap.jochen.org | principal name: imap/jupiter.jochen.org(a)JOCHEN.ORG | key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment | eku: id-kp-serverAuth,id-kp-clientAuth | pre-save command: | post-save command: /root/refresh_cyrus_certificate.sh | track: yes | auto-renew: yes `---- On an iPhone one of my users gets a message that the certificate is not valid.

Reason seems to be this: https://7402.org/blog/2019/new-self-signed-ssl-cert-ios-13.html

When I look at the certificate with openssl I see: ,---- | X509v3 extensions: | X509v3 Authority Key Identifier: | keyid:4F:F8:45:3D:E8:06:4B:8D:BB:9D:D2:D1:8B:00:43:A1:07:16:A1:17 | | Authority Information Access: | OCSP - URI:http://ipa-ca.jochen.org/ca/ocsp | | X509v3 Key Usage: critical | Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment | X509v3 Extended Key Usage: | TLS Web Server Authentication, TLS Web Client Authentication `---- My current guess is that the "Key Usage: critical" is the reason for the iOS error.

I've looked for the certprofiles and found these files: ,---- | [root@freeipa3 /]# find . -name \*caIPAserviceCert\* -ls | 8510694 8 -rw-rw---- 1 pkiuser pkiuser 6218 Mär 4 2020 ./var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg | 9332162 4 -rw-r--r-- 1 root root 229 Aug 20 12:38 ./usr/lib/python3.8/site-packages/ipaclient/csrgen/profiles/caIPAserviceCert.json | 26138015 8 -rw-r--r-- 1 root root 7014 Aug 20 12:37 ./usr/share/ipa/profiles/caIPAserviceCert.UPGRADE.cfg | 26138016 8 -rw-r--r-- 1 root root 7294 Aug 20 12:37 ./usr/share/ipa/profiles/caIPAserviceCert.cfg | 9323278 8 -rw-r--r-- 1 root root 6272 Jun 25 23:53 ./usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg `---- These files contain: ,---- | policyset.serverCertSet.6.constraint.params.keyUsageCritical=true | policyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true | policyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true | policyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true | policyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true | policyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false `---- So I think this is where the critical comes from and the keyUsage defaults come from. What I could use help with is the following: 1. I didn't find reports about the problem in pagure or the mailing list. Am I really alone with this?

2. My FreeIPA has been installed years ago on Fedora, moved to CentOS and this year back to Fedora by creating replicas. Has there been a problem with upgrading the certprofiles?

3. How can I remove the options from the certificate request so that certmonger gets a valid certificate?

Do I miss something else?

First of all: is the IPA CA certificate (or if it is externally signed, one of the superior certificates) in the trust store on the user's iPhone?

On Sun, Sep 06, 2020 at 11:24:22AM +0200, Jochen Kellner via FreeIPA-users wrote: > > Hello, > > I'm running IPA on current Fedora 32, freeipa-server-4.8.9-2 and pki-server-10.9.0-0.4 > > Today the certificate of my IMAP server (running on Debian Buster) was > automatically refreshed: > > ,---- > | Request ID '20181003215953': > | status: MONITORING > | stuck: no > | key pair storage: type=FILE,location='/etc/ssl/private/imap.jochen.org.key' > | certificate: type=FILE,location='/etc/ssl/certs/imap.jochen.org.crt' > | CA: IPA > | issuer: CN=Certificate Authority,O=JOCHEN.ORG > | subject: CN=imap.jochen.org,O=JOCHEN.ORG > | expires: 2022-09-07 09:30:16 CEST > | dns: imap.jochen.org > | principal name: imap/jupiter.jochen.org(a)JOCHEN.ORG > | key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > | eku: id-kp-serverAuth,id-kp-clientAuth > | pre-save command: > | post-save command: /root/refresh_cyrus_certificate.sh > | track: yes > | auto-renew: yes > `---- > > On an iPhone one of my users gets a message that the certificate is not valid. > Was the previous certificate accepted, and the problem only occurs with the new certificate. You did mention the recent renewal, but you please clarify on this point?

> Reason seems to be this: https://7402.org/blog/2019/new-self-signed-ssl-cert-ios-13.html > This article does not suggest any reason why iOS would consider the certificate invalid. If I missed something, please elaborate.

> When I look at the certificate with openssl I see: > > ,---- > | X509v3 extensions: > | X509v3 Authority Key Identifier: > | keyid:4F:F8:45:3D:E8:06:4B:8D:BB:9D:D2:D1:8B:00:43:A1:07:16:A1:17 > | > | Authority Information Access: > | OCSP - URI:http://ipa-ca.jochen.org/ca/ocsp > | > | X509v3 Key Usage: critical > | Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment > | X509v3 Extended Key Usage: > | TLS Web Server Authentication, TLS Web Client Authentication > `---- > > My current guess is that the "Key Usage: critical" is the reason for the iOS error. > This is almost certainly not the issue. "Critical" just means that a verifier must understand and process the extension, or else fail. Per RFC 5280 the Key Usage extension SHOULD be marked critical. The asserted values are appropriate for a TLS server.

> I've looked for the certprofiles and found these files: > > ,---- > | [root@freeipa3 /]# find . -name \*caIPAserviceCert\* -ls > | 8510694 8 -rw-rw---- 1 pkiuser pkiuser 6218 Mär 4 2020 ./var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg > | 9332162 4 -rw-r--r-- 1 root root 229 Aug 20 12:38 ./usr/lib/python3.8/site-packages/ipaclient/csrgen/profiles/caIPAserviceCert.json > | 26138015 8 -rw-r--r-- 1 root root 7014 Aug 20 12:37 ./usr/share/ipa/profiles/caIPAserviceCert.UPGRADE.cfg > | 26138016 8 -rw-r--r-- 1 root root 7294 Aug 20 12:37 ./usr/share/ipa/profiles/caIPAserviceCert.cfg > | 9323278 8 -rw-r--r-- 1 root root 6272 Jun 25 23:53 ./usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg > `---- > > These files contain: > > ,---- > | policyset.serverCertSet.6.constraint.params.keyUsageCritical=true > | policyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true > | policyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true > | policyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true > | policyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true > | policyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false > `---- > > So I think this is where the critical comes from and the keyUsage defaults come from. > > What I could use help with is the following: > > 1. I didn't find reports about the problem in pagure or the mailing > list. Am I really alone with this? > Possibly, or you could be the canary in the coal mine :) You should first confirm that the affect iOS system actually trusts the CA certificate before pursuing other lines of investigation.

> 2. My FreeIPA has been installed years ago on Fedora, moved to CentOS > and this year back to Fedora by creating replicas. Has there been a > problem with upgrading the certprofiles? > I think the profile configuration is fine.

> 3. How can I remove the options from the certificate request so that > certmonger gets a valid certificate? > Not relevant. > Do I miss something else? > If it is not a CA trust issue, the next thing I would suggest to try is to modify the caIPAserviceCert profile to issue a certificate with a validity period of <398 days. Browsers recently implemented a change that certificates issued from September 2020 must have a maximum validity period of 398 days. This change SHOULD only apply for certification paths ending at publicly trusted CAs. But maybe Apple pushed an update that applies it across the board. To modify the profile: 1. export the configuration: `ipa certprofile-show --out profile.cfg caIPAserviceCert` 2. edit the validity period in the profile configuration: policyset.serverCertSet.2.constraint.params.range=380 3. modify the profile `ipa certprofile-mod --file profile.cfg caIPAserviceCert` 4. On the IMAP server host use certmonger to reissue the IMAP certificate: `getcert resubmit -i 20181003215953`

Hello, thanks for your suggestions, I'll answer below. TL;DR: seems to work now. Fraser Tweedale via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org&gt; writes: > First of all: is the IPA CA certificate (or if it is externally > signed, one of the superior certificates) in the trust store on the > user's iPhone? I use the CA from FreeIPA and the CA certificate has been imported in the trust store. Using a web browser to access an internal website with an (older) IPA issued certificate works/validates fine. > On Sun, Sep 06, 2020 at 11:24:22AM +0200, Jochen Kellner via FreeIPA-users wrote: >> >> Hello, >> >> I'm running IPA on current Fedora 32, freeipa-server-4.8.9-2 and pki-server-10.9.0-0.4 >> >> Today the certificate of my IMAP server (running on Debian Buster) was >> automatically refreshed: >> >> ,---- >> | Request ID '20181003215953': >> | status: MONITORING >> | stuck: no >> | key pair storage: type=FILE,location='/etc/ssl/private/imap.jochen.org.key' >> | certificate: type=FILE,location='/etc/ssl/certs/imap.jochen.org.crt' >> | CA: IPA >> | issuer: CN=Certificate Authority,O=JOCHEN.ORG >> | subject: CN=imap.jochen.org,O=JOCHEN.ORG >> | expires: 2022-09-07 09:30:16 CEST >> | dns: imap.jochen.org >> | principal name: imap/jupiter.jochen.org(a)JOCHEN.ORG >> | key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> | eku: id-kp-serverAuth,id-kp-clientAuth >> | pre-save command: >> | post-save command: /root/refresh_cyrus_certificate.sh >> | track: yes >> | auto-renew: yes >> `---- >> >> On an iPhone one of my users gets a message that the certificate is not valid. >> > Was the previous certificate accepted, and the problem only occurs > with the new certificate. You did mention the recent renewal, but > you please clarify on this point? Yes, the old certificate was accepted without problems. Only after the renewal the user got these messages. >> Reason seems to be this: https://7402.org/blog/2019/new-self-signed-ssl-cert-ios-13.html >> > This article does not suggest any reason why iOS would consider the > certificate invalid. If I missed something, please elaborate. This is the part: The new requirements for an SSL certificate to be accepted by iOS 13 and macOS 10.15 are given in https://support.apple.com/en-us/HT210176. The key points are: Key size must be greater than or equal to 2048 bits. Certificate must have a validity period of 825 days or fewer. Don't sign the certificate with SHA-1. DNS name must be in the Subject Alternative Name extension of the certificate. Certificate must have an ExtendedKeyUsage containing serverAuth. >> When I look at the certificate with openssl I see: >> >> ,---- >> | X509v3 extensions: >> | X509v3 Authority Key Identifier: >> | keyid:4F:F8:45:3D:E8:06:4B:8D:BB:9D:D2:D1:8B:00:43:A1:07:16:A1:17 >> | >> | Authority Information Access: >> | OCSP - URI:http://ipa-ca.jochen.org/ca/ocsp >> | >> | X509v3 Key Usage: critical >> | Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment >> | X509v3 Extended Key Usage: >> | TLS Web Server Authentication, TLS Web Client Authentication >> `---- >> >> My current guess is that the "Key Usage: critical" is the reason for the iOS error. >> > This is almost certainly not the issue. "Critical" just means that > a verifier must understand and process the extension, or else fail. > Per RFC 5280 the Key Usage extension SHOULD be marked critical. > The asserted values are appropriate for a TLS server. Ok. >> I've looked for the certprofiles and found these files: >> >> ,---- >> | [root@freeipa3 /]# find . -name \*caIPAserviceCert\* -ls >> | 8510694 8 -rw-rw---- 1 pkiuser pkiuser 6218 Mär 4 2020 ./var/lib/pki/pki-tomcat/ca/profiles/ca/caIPAserviceCert.cfg >> | 9332162 4 -rw-r--r-- 1 root root 229 Aug 20 12:38 ./usr/lib/python3.8/site-packages/ipaclient/csrgen/profiles/caIPAserviceCert.json >> | 26138015 8 -rw-r--r-- 1 root root 7014 Aug 20 12:37 ./usr/share/ipa/profiles/caIPAserviceCert.UPGRADE.cfg >> | 26138016 8 -rw-r--r-- 1 root root 7294 Aug 20 12:37 ./usr/share/ipa/profiles/caIPAserviceCert.cfg >> | 9323278 8 -rw-r--r-- 1 root root 6272 Jun 25 23:53 ./usr/share/pki/ca/profiles/ca/caIPAserviceCert.cfg >> `---- >> >> These files contain: >> >> ,---- >> | policyset.serverCertSet.6.constraint.params.keyUsageCritical=true >> | policyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true >> | policyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true >> | policyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true >> | policyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true >> | policyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false >> `---- >> >> So I think this is where the critical comes from and the keyUsage defaults come from. >> >> What I could use help with is the following: >> >> 1. I didn't find reports about the problem in pagure or the mailing >> list. Am I really alone with this? >> > > Possibly, or you could be the canary in the coal mine :) You should > first confirm that the affect iOS system actually trusts the CA > certificate before pursuing other lines of investigation. Ok, I'll recheck. And that really was an issue: The CA certificate had been imported into the trust store. In another settings menue (german iOS: Info -> Zertifikatsvertrauensstellung) the CA was not marked as trusted. We've enabled that and right now didn't get the error messages while getting new mail. I'll have the user monitor and confirm, but hopefully we can close this case. >> 2. My FreeIPA has been installed years ago on Fedora, moved to CentOS >> and this year back to Fedora by creating replicas. Has there been a >> problem with upgrading the certprofiles? >> > I think the profile configuration is fine. Thanks for the confirmation. >> 3. How can I remove the options from the certificate request so that >> certmonger gets a valid certificate? >> > Not relevant. > >> Do I miss something else? >> > > If it is not a CA trust issue, the next thing I would suggest to try > is to modify the caIPAserviceCert profile to issue a certificate > with a validity period of <398 days. Browsers recently implemented > a change that certificates issued from September 2020 must have a > maximum validity period of 398 days. This change SHOULD only apply > for certification paths ending at publicly trusted CAs. But maybe > Apple pushed an update that applies it across the board. > > To modify the profile: > > 1. export the configuration: > `ipa certprofile-show --out profile.cfg caIPAserviceCert` > > 2. edit the validity period in the profile configuration: > policyset.serverCertSet.2.constraint.params.range=380 > > 3. modify the profile > `ipa certprofile-mod --file profile.cfg caIPAserviceCert` > > 4. On the IMAP server host use certmonger to reissue the IMAP > certificate: `getcert resubmit -i 20181003215953` Maybe that's a good idea anyway - when certificates get renewed every couple of month like letsencrypt I'll find errors in the renewal much earlier. If the renewal is manual a long validity period is useful, but when everything is automatically a short validity period is no hassle and indeed useful to catch errors early. Jochen

We had a developer team deploy their own CA and then issue a slew of certificates for users' workstations and other servers, and now they want us to deploy those certificates more widely. I'd rather find a way to bring their CA under ours so that the root CA certificate we already distribute will make theirs "just work" rather than having to distribute another set of root CA certificates. Is this possible, or would they have to start over and build a subordinate CA from the ground up to make it work? If it's perhaps possible, under what circumstances?

Thanks! Bret _______________________________________________ FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

Fraser, It doesn't look like we fit the model. Our IPA CA's cert is as expected, but the other one is: $ openssl x509 -noout -in web-ca.crt -issuer issuer= /C=US/ST=VA/L=Fairfax/O=DG Web Team/OU=DG/CN=damascusgrp.com DG Web Team Root CA Since I don't see a hostname in there anywhere (and in fact, further conversations with this team turned up the fact that they're just creating these by hand using openssl commands rather than running any sort of service at all), I'm hesitant to just barge ahead and try to make it work on my own...

-- Bret Wortman bret.wortman(a)damascusgrp.com On Mon, Feb 15, 2021, at 8:30 PM, Fraser Tweedale wrote: > On Mon, Feb 15, 2021 at 10:10:59AM -0500, Bret Wortman via FreeIPA-users wrote: > > We had a developer team deploy their own CA and then issue a slew > > of certificates for users' workstations and other servers, and now > > they want us to deploy those certificates more widely. I'd rather > > find a way to bring their CA under ours so that the root CA > > certificate we already distribute will make theirs "just work" > > rather than having to distribute another set of root CA > > certificates. > > > > Is this possible, or would they have to start over and build a > > subordinate CA from the ground up to make it work? If it's perhaps > > possible, under what circumstances? > > > Hi Bret, > > It is possible, but there are restrictions about what the sub-CAs > subject DN can be. Have a read of this blog post: > https://frasertweedale.github.io/blog-redhat/posts/2018-08-21-ipa-subordi... > > If your developer team's CA certificate does not fit those > requirements, please share the details of the certificate > (especially Subject DN) and I'll see if I can find a workaround. > > Cheers, > Fraser > > > > > Thanks! > > > > Bret > > _______________________________________________ > > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho... > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > >

Because the full CN is actually "damascusgrp.com DG Web Team Root CA", does that complicate this or do I just need to find a way to add all that as a host?

-- Bret Wortman bret.wortman(a)damascusgrp.com On Tue, Feb 16, 2021, at 8:06 AM, Bret Wortman wrote: > I may well have messed this up, but here's what I've done: > > # ipa host-add --force damascusgrp.com > ---------------------------- > Added host "damascusgrp.com" > ---------------------------- > Host name: damascusgrp.com > Principal name: host/damascusgrp.com(a)DAMASCUSGRP.COM > Principal alias: host/damascusgrp.com(a)DAMASCUSGRP.COM > Password: False > Member of host-groups: allow_all_hosts > Indirect Member of netgroup: allow_all_hosts > Keytab: False > Managed by: damascusgrp.com > # ipa certprofile-show caIPAserviceCert --out SubCA.cfg > ------------------------------------------------ > Profile configuration stored in file "SubCA.cfg" > ------------------------------------------------ > Profile ID: caIPAserviceCert > Profile description: Standard profile for network services > Store issued certificates: TRUE > # vim SubCA.cfg > : > profileId=damascusgrp.com > : > # ipa certprofile-import 'damascusgrp.com' --desc "Web Team CA" --file > SubCA.cfg --store=1 > ipa: ERROR: invalid 'id': invalid Profile ID > > > -- > Bret Wortman > bret.wortman(a)damascusgrp.com > > On Tue, Feb 16, 2021, at 7:40 AM, Bret Wortman wrote: > > Just to be clear, I'm going to follow the steps, but instead of setting > > up sub.ipa.local, I'm going to instead use simply "damascusgrp.com", > > yielding a principal named host/damascusgrp.com(a)DAMASCUSGRP.COM, right? > > And then proceed through the rest of the steps. > > > > > > -- > > Bret Wortman > > bret.wortman(a)damascusgrp.com > > > > On Tue, Feb 16, 2021, at 7:05 AM, Bret Wortman wrote: > > > Okay, I'll give it a try. Thanks! > > > > > > > > > -- > > > Bret Wortman > > > bret.wortman(a)damascusgrp.com > > > > > > On Tue, Feb 16, 2021, at 6:59 AM, Fraser Tweedale wrote: > > > > On Tue, Feb 16, 2021 at 05:53:31AM -0500, Bret Wortman wrote: > > > > > Fraser, > > > > > > > > > > It doesn't look like we fit the model. Our IPA CA's cert is as > > > > > expected, but the other one is: > > > > > > > > > > $ openssl x509 -noout -in web-ca.crt -issuer issuer= > > > > > /C=US/ST=VA/L=Fairfax/O=DG Web Team/OU=DG/CN=damascusgrp.com DG > > > > > Web Team Root CA > > > > > > > > > > Since I don't see a hostname in there anywhere (and in fact, > > > > > further conversations with this team turned up the fact that > > > > > they're just creating these by hand using openssl commands rather > > > > > than running any sort of service at all), I'm hesitant to just > > > > > barge ahead and try to make it work on my own... > > > > > > > > The CN (damascusgrp.com) is a domain name. You can add a host > > > > object with that name to FreeIPA. I think the procedure outlined in > > > > the blog post should work for you. > > > > > > > > Cheers, > > > > Fraser > > > > > > > > > > > > > > -- > > > > > Bret Wortman > > > > > bret.wortman(a)damascusgrp.com > > > > > > > > > > On Mon, Feb 15, 2021, at 8:30 PM, Fraser Tweedale wrote: > > > > > > On Mon, Feb 15, 2021 at 10:10:59AM -0500, Bret Wortman via FreeIPA-users wrote: > > > > > > > We had a developer team deploy their own CA and then issue a slew > > > > > > > of certificates for users' workstations and other servers, and now > > > > > > > they want us to deploy those certificates more widely. I'd rather > > > > > > > find a way to bring their CA under ours so that the root CA > > > > > > > certificate we already distribute will make theirs "just work" > > > > > > > rather than having to distribute another set of root CA > > > > > > > certificates. > > > > > > > > > > > > > > Is this possible, or would they have to start over and build a > > > > > > > subordinate CA from the ground up to make it work? If it's perhaps > > > > > > > possible, under what circumstances? > > > > > > > > > > > > > Hi Bret, > > > > > > > > > > > > It is possible, but there are restrictions about what the sub-CAs > > > > > > subject DN can be. Have a read of this blog post: > > > > > > https://frasertweedale.github.io/blog-redhat/posts/2018-08-21-ipa-subordi... > > > > > > > > > > > > If your developer team's CA certificate does not fit those > > > > > > requirements, please share the details of the certificate > > > > > > (especially Subject DN) and I'll see if I can find a workaround. > > > > > > > > > > > > Cheers, > > > > > > Fraser > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > Bret > > > > > > > _______________________________________________ > > > > > > > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > > > > > > > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > > > > > > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > > > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > > > > List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho... > > > > > > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > > > > > > > > > > > > > > > > > > > > > > > >