Julita Inca Chiroque: #PeruRumboGSoC2018 – Session 2

Share Button

Thanks to the permission of the Professor Jorge Mirez, we had a space in the laboratory of CTIC, to carry out our trainning last Sunday from 9:00 am to 6:00 pm.

According to the plan, the entire session was dedicated to C programming language. Martin Vuelta was in charge of the workshop and these are the references.

Basically, we did a review of the basis of C, the GCC compiler, pointers, structs and a make file to compile our C codes. The session is available on the Road-to-GSoC2018 Part1 repo.

We started by taking a 20 minutes quizz of the previuos GNU/Linux session and the answer had to be published on their git accounts in a form of script e.g. @aweba @dahsser 

We did a mini celebration for the Peru World Cup with our white and red t-shirts, followed by a lunch at the restaurant, thanks to the sponsor of GNOME.

Four more sessions are waiting for us, the effort of the participant who has finished and passed the program successfully (based on git, posts, quizzes) will be prized, thanks to the Linux Foundation scholarship and a nice black sweatshirt of the program. Best luck guys!

Filed under: Education, Events, FEDORA, GNOME Tagged: #PeruRumboGSoC2018, fedora, git, GNOME, GSoC 2018, Julita Inca, Julita Inca Chiroque, Lima, Linux Foundation, Linux program, Linux quizz, Perú, post

Powered by WPeMatico

Share Button

Allan Day: GNOME Shell UX Hackfest

Share Button

GNOME Shell has made significant improvements over the years since GNOME 3.0 was first released. This has included overhauling notifications, introducing a unified system status area, and refining how window selection and application launching works. Additionally, a huge amount of work has gone into polishing the experience through many many small improvements.

At the same time, some of the core elements of the GNOME Shell experience haven’t significantly changed for some time, and I have started to feel that a round of improvements is due, both to address long-standing issues and to ensure that the shell continues to develop in ways that our users value.

GNOME is also in the fantastic position of having new partners who we are developing working relationships with, particularly around the shell. Nowadays there are a variety of derivatives who are using the shell, including Endless, Ubuntu and Pop!_OS, and there’s a real desire to collaborate over the future of the shell and share in any benefits that might result.

Last week, these twin desires coalesced as a user experience hackfest which aimed to improve the design of the shell.

The hackfest was deliberately small, in order to provide a conducive environment for design work. Participants included Robin Tafel, Cosimo Cecchi, Jakub Steiner, Tobias Bernard, Florian Müllner, Cassidy James Blaede, Mario Sanchez Prada and myself (Nick Richards also called in). These individuals had affiliations with Endless, Red Hat, System76 and elementary OS, and they included both experienced GNOME designers and fresh perspectives.

While there wasn’t anyone from Ubuntu at the hackfest, we are in contact and I’ll be working to ensure that they are included in the process that the hackfest has initiated.

Overall, I was extremely happy with the event, and we came away with some exciting plans, which we think will result in major improvements to the GNOME Shell user experience.

Turning the ideas we’ve generated into viable designs will be a lot of work, and I’ll provide more details once some of the details have been filled in. In the mean time, Cassidy has written up a detailed account of the hackfest, which includes some more specifics for those who are especially interested.

I’d like to thank the GNOME Foundation for sponsoring my attendance at the hackfest, as well as Endless and Red Hat for providing the space for the event. I’d also like to offer my heartfelt gratitude to all the attendees, every one of whom made valuable and talented contributions over the four days.

Photo courtesy of Jakub Steiner (CC-BY-SA 2.0).

Powered by WPeMatico

Share Button

Fraser Tweedale: Changing a CA’s Subject DN; Part II: FreeIPA

Share Button

In the previous post I explained how the CA Subject DN is an integral part of X.509 any why you should not change it. Doing so can break path validation, CRLs and OCSP, and many programs will not copye with the change. I proposed some alternative approaches that avoid these problems: re-chaining the CA, and creating subordinate CAs.

If you were thinking of changing your CA’s Subject DN, I hope that I dissuaded you. But if I failed, or you absolutely do need to change the Subject DN of your CA, where there’s a will there’s way. The purpose of this post is to explore how to do this in FreeIPA, and discuss the implications.

This is a long post. If you are really changing the CA subject DN, don’t skip anything. Otherwise don’t feel back about skimming or jumping straight to the discussion. Even skimming the article will give you an idea of the steps involved, and how to repair the ensuing breakage.

Changing the FreeIPA CA’s Subject DN

Before writing this post, I had never even attempted to do this. I am unaware of anyone else trying or whether they were successful. But the question of how to do it has come up several times, so I decided to investigate. The format of this post follows my exploration of the topic as I poked and prodded a FreeIPA deployment, working towards the goal.

What was the goal? Let me state the goal, and some assumptions:

  • The goal is to give the FreeIPA CA a new Subject DN. The deployment should look and behave as though it were originally installed with the new Subject.
  • We want to keep the old CA certificate in the relevant certificate stores and databases, alongside the new certificate.
  • The CA is not being re-keyed (I will deal with re-keying in a future article).
  • We want to be able to do this with both self-signed and externally-signed CAs. It’s okay if the process differs.
  • It’s okay to have manual steps that the administrator must perform.

Let’s begin on the deployment’s CA renewal master.

Certmonger (first attempt)

There is a Certmonger tracking request for the FreeIPA CA, which uses the dogtag-ipa-ca-renew-agent CA helper. The getcert resubmit command lets you change the Subject DN when you resubmit a request, via the -N option. I know the internals of the CA helper and I can see that there will be problems after renewing the certificate this way. Storing the certificate in the ca_renewal LDAP container will fail. But the renewal itself might succeed so I’ll try it and see what happens:

[root@f27-2 ~]# getcert resubmit -i 20171106062742 
  -N 'CN=IPA.LOCAL CA 2017.11.09'
Resubmitting "20171106062742" to "dogtag-ipa-ca-renew-agent".

After waiting about 10 seconds for Certmonger to do its thing, I check the state of the tracking request:

[root@f27-2 ~]# getcert list -i 20171106062742
Request ID '20171106062742':
  status: MONITORING
  CA: dogtag-ipa-ca-renew-agent
  issuer: CN=Certificate Authority,O=IPA.LOCAL 201711061603
  subject: CN=Certificate Authority,O=IPA.LOCAL 201711061603
  expires: 2037-11-06 17:26:21 AEDT
  ... (various fields omitted)

The status and expires fields show that renewal succeeded, but the certificate still has the old Subject DN. This happened because the dogtag-ipa-ca-renew-agent helper doesn’t think it is renewing the CA certificate (which is true!)

Modifying the IPA CA entry

So let’s trick the Certmonger renewal helper. dogtag-ipa-ca-renew-agent looks up the CA Subject DN in the ipaCaSubjectDn attribute of the ipa CA entry (cn=ipa,cn=cas,cn=ca,{basedn}). This attribute is not writeable via the IPA framework but you can change it using regular LDAP tools (details out of scope). If the certificate is self-signed you should also change the ipaCaIssuerDn attribute. After modifying the entry run ipa ca-show to verify that these attributes have the desired values:

[root@f27-2 ~]# ipa ca-show ipa
  Name: ipa
  Description: IPA CA
  Authority ID: cdbfeb5a-64d2-4141-98d2-98c005802fc1
  Subject DN: CN=IPA.LOCAL CA 2017.11.09
  Issuer DN: CN=IPA.LOCAL CA 2017.11.09
  Certificate: MIIDnzCCAoegAwIBAgIBCTANBgkqhkiG9w0...

Certmonger (second attempt)

Now let’s try and renew the CA certificate via Certmonger again:

[root@f27-2 ~]# getcert resubmit -i 20171106062742 
  -N 'CN=IPA.LOCAL CA 2017.11.09'
Resubmitting "20171106062742" to "dogtag-ipa-ca-renew-agent".

Checking the getcert list output after a short wait:

[root@f27-2 ~]# getcert list -i 20171106062742
Request ID '20171106062742':
  status: MONITORING
  CA: dogtag-ipa-ca-renew-agent
  issuer: CN=Certificate Authority,O=IPA.LOCAL 201711061603
  subject: CN=IPA.LOCAL CA 2017.11.09
  expires: 2037-11-09 16:11:12 AEDT
  ... (various fields omitted)

Progress! We now have a CA certificate with the desired Subject DN. The new certificate has the old (current) issuer DN. We’ll ignore that for now.

Checking server health

Now I need to check the state of the deployment. Did anything go wrong during renewal? Is everything working?

First, I checked the Certmonger journal output to see if there were any problems. The journal contained the following messages (some fields omitted for brevity):

16:11:17 /dogtag-ipa-ca-renew-agent-submit[1662]: Forwarding request to dogtag-ipa-renew-agent
16:11:17 /dogtag-ipa-ca-renew-agent-submit[1662]: dogtag-ipa-renew-agent returned 0
16:11:19 /stop_pkicad[1673]: Stopping pki_tomcatd
16:11:20 /stop_pkicad[1673]: Stopped pki_tomcatd
16:11:22 /renew_ca_cert[1710]: Updating CS.cfg
16:11:22 /renew_ca_cert[1710]: Updating CA certificate failed: no matching entry found
16:11:22 /renew_ca_cert[1710]: Starting pki_tomcatd
16:11:34 /renew_ca_cert[1710]: Started pki_tomcatd
16:11:34 certmonger[2013]: Certificate named "caSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/etc/pki/pki-tomcat/alias" issued by CA and saved.

We can see that the renewal succeeded and Certmonger saved the new certificate in the NSSDB. Unfortunately there was an error in the renew_ca_cert post-save hook: it failed to store the new certificate in the LDAP certstore. That should be easy to resolve. I’ll make a note of that and continue checking deployment health.

Next, I checked whether Dogtag was functioning. systemctl status pki-tomcatd@pki-tomcat and the CA debug log (/var/log/pki/pki-tomcat/ca/debug) indicated that Dogtag started cleanly. Even better, the Dogtag NSSDB has the new CA certificate with the correct nickname:

[root@f27-2 ~]# certutil -d /etc/pki/pki-tomcat/alias 
  -L -n 'caSigningCert cert-pki-ca'
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 11 (0xb)
        Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
        Issuer: "CN=Certificate Authority,O=IPA.LOCAL 201711061603"
        Validity:
            Not Before: Thu Nov 09 05:11:12 2017
            Not After : Mon Nov 09 05:11:12 2037
        Subject: "CN=IPA.LOCAL CA 2017.11.09"
  ... (remaining lines omitted)

We have not yet confirmed that the Dogtag uses the new CA Subject DN as the Issuer DN on new certificates (we’ll check this later).

Now let’s check the state of IPA itself. There is a problem in communication between the IPA framework and Dogtag:

[root@f27-2 ~]# ipa ca-show ipa
ipa: ERROR: Request failed with status 500: Non-2xx response from CA REST API: 500.

A quick look in /var/log/httpd/access_log showed that it was not a general problem but only occurred when accessing a particular resource:

[09/Nov/2017:17:15:09 +1100] "GET https://f27-2.ipa.local:443/ca/rest/authorities/cdbfeb5a-64d2-4141-98d2-98c005802fc1/cert HTTP/1.1" 500 6201

That is a Dogtag lightweight authority resource for the CA identified by cdbfeb5a-64d2-4141-98d2-98c005802fc1. That is the CA ID recorded in the FreeIPA ipa CA entry. This gives a hint about where the problem lies. An ldapsearch reveals more:

[f27-2:~] ftweedal% ldapsearch -LLL 
    -D 'cn=directory manager' -w DM_PASSWORD 
    -b 'ou=authorities,ou=ca,o=ipaca' -s one
dn: cn=cdbfeb5a-64d2-4141-98d2-98c005802fc1,ou=authorities,ou=ca,o=ipaca
authoritySerial: 9
objectClass: authority
objectClass: top
cn: cdbfeb5a-64d2-4141-98d2-98c005802fc1
authorityID: cdbfeb5a-64d2-4141-98d2-98c005802fc1
authorityKeyNickname: caSigningCert cert-pki-ca
authorityEnabled: TRUE
authorityDN: CN=Certificate Authority,O=IPA.LOCAL 201711061603
description: Host authority

dn: cn=008a4ded-fd4b-46fe-8614-68518123c95f,ou=authorities,ou=ca,o=ipaca
objectClass: authority
objectClass: top
cn: 008a4ded-fd4b-46fe-8614-68518123c95f
authorityID: 008a4ded-fd4b-46fe-8614-68518123c95f
authorityKeyNickname: caSigningCert cert-pki-ca
authorityEnabled: TRUE
authorityDN: CN=IPA.LOCAL CA 2017.11.09
description: Host authority

There are now two authority entries when there should be one. During startup, Dogtag makes sure it has an authority entry for the main (“host”) CA. It compares the Subject DN from the signing certificate in its NSSDB to the authority entries. If it doesn’t find a match it creates a new entry, and that’s what happened here.

The resolution is straightforward:

  1. Stop Dogtag
  2. Update the authorityDN and authoritySerial attributes of the original host authority entry.
  3. Delete the new host authority entry.
  4. Restart Dogtag.

Now the previous ldapsearch returns one entry, with the original authority ID and correct attribute values:

[f27-2:~] ftweedal% ldapsearch -LLL 
    -D 'cn=directory manager' -w DM_PASSWORD 
    -b 'ou=authorities,ou=ca,o=ipaca' -s one
dn: cn=cdbfeb5a-64d2-4141-98d2-98c005802fc1,ou=authorities,ou=ca,o=ipaca
authoritySerial: 11
authorityDN: CN=IPA.LOCAL CA 2017.11.09
objectClass: authority
objectClass: top
cn: cdbfeb5a-64d2-4141-98d2-98c005802fc1
authorityID: cdbfeb5a-64d2-4141-98d2-98c005802fc1
authorityKeyNickname: caSigningCert cert-pki-ca
authorityEnabled: TRUE
description: Host authority

And the operations that were failing before (e.g. ipa ca-show ipa) now succeed. So we’ve confirmed, or restored, the basic functionality on this server.

LDAP certificate stores

There are two LDAP certificate stores in FreeIPA. The first is cn=ca_renewal,cn=ipa,cn=etc,{basedn}. It is only used for replicating Dogtag CA and system certificates from the CA renewal master to CA replicas. The dogtag-ipa-ca-renew-agent Certmonger helper should update the cn=caSigningCert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,{basedn} entry after renewing the CA certificate. A quick ldapsearch shows that this succeeded, so there is nothing else to do here.

The other certificate store is cn=certificates,cn=ipa,cn=etc,{basedn}. This store contains trusted CA certificates. FreeIPA clients and servers retrieve certificates from this directory when updating their certificate trust stores. Certificates are stored in this container with a cn based on the Subject DN, except for the IPA CA which is stored with cn={REALM-NAME} IPA CA. (In my case, this is cn=IPA.LOCAL IPA CA.)

We discovered the failure to update this certificate store earlier (in the Certmonger journal). Now we must fix it up. We still want to trust certificates with the old Issuer DN, otherwise we would have to reissue all of them. So we need to keep the old CA certificate in the store, alongside the new.

The process to fix up the certificate store is:

  1. Export the new CA certificate from the Dogtag NSSDB to a file:

    [root@f27-2 ~]# certutil -d /etc/pki/pki-tomcat/alias 
       -L -a -n 'caSigningCert cert-pki-ca' > new-ca.crt
  2. Add the new CA certificate to the certificate store:

    [root@f27-2 ~]# ipa-cacert-manage install new-ca.crt
    Installing CA certificate, please wait
    CA certificate successfully installed
    The ipa-cacert-manage command was successful
  3. Rename (modrdn) the existing cn={REALM-NAME} IPA CA entry. The new cn RDN is based on the old CA Subject DN.
  4. Rename the new CA certificate entry. The current cn is the new Subject DN. Rename it to cn={REALM-NAME} IPA CA. I encountered a 389DS attribute uniqueness error when I attempted to do this as a modrdn operation. I’m not sure why it happened. To work around the problem I deleted the entry and added it back with the new cn.

At the end of this procedure the certificate store is as it should be. The CA certificate with new Subject DN is installed as {REALM-NAME} IPA CA and the old CA certificate has been preserved under a different RDN.

Updating certificate databases

The LDAP certificate stores have the new CA certificate. Now we need to update the other certificate databases so that the programs that use them will trust certificates with the new Issuer DN. These databases include:

/etc/ipa/ca.crt

CA trust store used by the IPA framework

/etc/ipa/nssdb

An NSSDB used by FreeIPA

/etc/dirsrv/slapd-{REALM-NAME}

NSSDB used by 389DS

/etc/httpd/alias

NSSDB used by Apache HTTPD

/etc/pki/ca-trust/source/ipa.p11-kit

Adds FreeIPA CA certificates to the system-wide trust store

Run ipa-certupdate to update these databases with the CA certificates from the LDAP CA certificate store:

[root@f27-2 ~]# ipa-certupdate
trying https://f27-2.ipa.local/ipa/json
[try 1]: Forwarding 'schema' to json server 'https://f27-2.ipa.local/ipa/json'
trying https://f27-2.ipa.local/ipa/session/json
[try 1]: Forwarding 'ca_is_enabled/1' to json server 'https://f27-2.ipa.local/ipa/session/json'
[try 1]: Forwarding 'ca_find/1' to json server 'https://f27-2.ipa.local/ipa/session/json'
failed to update IPA.LOCAL IPA CA in /etc/dirsrv/slapd-IPA-LOCAL: Command '/usr/bin/certutil -d /etc/dirsrv/slapd-IPA-LOCAL -A -n IPA.LOCAL IPA CA -t C,, -a -f /etc/dirsrv/slapd-IPA-LOCAL/pwdfile.txt' returned non-zero exit status 255.
failed to update IPA.LOCAL IPA CA in /etc/httpd/alias: Command '/usr/bin/certutil -d /etc/httpd/alias -A -n IPA.LOCAL IPA CA -t C,, -a -f /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 255.
failed to update IPA.LOCAL IPA CA in /etc/ipa/nssdb: Command '/usr/bin/certutil -d /etc/ipa/nssdb -A -n IPA.LOCAL IPA CA -t C,, -a -f /etc/ipa/nssdb/pwdfile.txt' returned non-zero exit status 255.
Systemwide CA database updated.
Systemwide CA database updated.
The ipa-certupdate command was successful
[root@f27-2 ~]# echo $?
0

ipa-certupdate reported that it was successful and it exited cleanly. But a glance at the output shows that not all went well. There were failures added the new CA certificate to several NSSDBs. Running one of the commands manually to see the command output doesn’t give us much more information:

[root@f27-2 ~]# certutil -d /etc/ipa/nssdb -f /etc/ipa/nssdb/pwdfile.txt 
    -A -n 'IPA.LOCAL IPA CA' -t C,, -a < ~/new-ca.crt
certutil: could not add certificate to token or database: SEC_ERROR_ADDING_CERT: Error adding certificate to database.
[root@f27-2 ~]# echo $?
255

At this point I guessed that because there is already a certificate stored with the nickname IPA.LOCAL IPA CA, NSS refuses to add a certificate with a different Subject DN under the same nickname. So I will delete the certificates with this nickname from each of the NSSDBs, then try again. For some reason the nickname appeared twice in each NSSDB:

[root@f27-2 ~]# certutil -d /etc/dirsrv/slapd-IPA-LOCAL -L

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

CN=alt-f27-2.ipa.local,O=Example Organization                u,u,u
CN=CA,O=Example Organization                                 C,,
IPA.LOCAL IPA CA                                             CT,C,C
IPA.LOCAL IPA CA                                             CT,C,C

So for each NSSDB, to delete the certificate I had to execute the certutil command twice. For the 389DS NSSDB, the command was:

[root@f27-2 ~]# certutil -d /etc/httpd/alias -D -n "IPA.LOCAL IPA CA"

The commands for the other NSSDBs were similar. With the problematic certificates removed, I tried running ipa-certupdate again:

[root@f27-2 ~]# ipa-certupdate
trying https://f27-2.ipa.local/ipa/session/json
[try 1]: Forwarding 'ca_is_enabled/1' to json server 'https://f27-2.ipa.local/ipa/session/json'
[try 1]: Forwarding 'ca_find/1' to json server 'https://f27-2.ipa.local/ipa/session/json'
Systemwide CA database updated.
Systemwide CA database updated.
The ipa-certupdate command was successful
[root@f27-2 ~]# echo $?
0

This time there were no errors. certutil shows an IPA.LOCAL IPA CA certificate in the database, and it’s the right certificate:

[root@f27-2 ~]# certutil -d /etc/dirsrv/slapd-IPA-LOCAL -L

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

CN=alt-f27-2.ipa.local,O=Example Organization                u,u,u
CN=CA,O=Example Organization                                 C,,
CN=Certificate Authority,O=IPA.LOCAL 201711061603            CT,C,C
CN=Certificate Authority,O=IPA.LOCAL 201711061603            CT,C,C
IPA.LOCAL IPA CA                                             C,,
[root@f27-2 ~]# certutil -d /etc/dirsrv/slapd-IPA-LOCAL -L -n 'IPA.LOCAL IPA CA'
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 11 (0xb)
        Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
        Issuer: "CN=Certificate Authority,O=IPA.LOCAL 201711061603"
        Validity:
            Not Before: Thu Nov 09 05:11:12 2017
            Not After : Mon Nov 09 05:11:12 2037
        Subject: "CN=IPA.LOCAL CA 2017.11.09"
        ...

I also confirmed that the old and new CA certificates are present in the /etc/ipa/ca.crt and /etc/pki/ca-trust/source/ipa.p11-kit files. So all the certificate databases now include the new CA certificate.

Renewing the CA certificate (again)

Observe that (in the self-signed FreeIPA CA case) the Issuer DN of the new CA certificate is the Subject DN of the old CA certificate. So we have not quite reached out goal. The original CA certificate was self-signed, so we want a self-signed certificate with the new Subject.

Renewing the CA certificate one more time should result in a self-signed certificate. The current situation is not likely to result in operational issues. So you can consider this an optional step. Anyhow, let’s give it a go:

[root@f27-2 ~]# getcert list -i 20171106062742 | egrep 'status|issuer|subject'
        status: MONITORING
        issuer: CN=Certificate Authority,O=IPA.LOCAL 201711061603
        subject: CN=IPA.LOCAL CA 2017.11.09
[root@f27-2 ~]# getcert resubmit -i 20171106062742
Resubmitting "20171106062742" to "dogtag-ipa-ca-renew-agent".
[root@f27-2 ~]# sleep 5
[root@f27-2 ~]# getcert list -i 20171106062742 | egrep 'status|issuer|subject'
        status: MONITORING
        issuer: CN=IPA.LOCAL CA 2017.11.09
        subject: CN=IPA.LOCAL CA 2017.11.09

Now we have a self-signed CA cert with the new Subject DN. This step has also confirmed that that the certificate issuance is working fine with the new CA subject.

Renewing FreeIPA service certificates

This is another optional step, because we have kept the old CA certificate in the trust store. I want to check that certificate renewals via the FreeIPA framework are working, and this is a fine way to do that.

I’ll renew the HTTP service certificate. This deployment is using an externally-signed HTTP certificate so first I had to track it:

[root@f27-2 ~]# getcert start-tracking 
  -d /etc/httpd/alias -p /etc/httpd/alias/pwdfile.txt 
  -n 'CN=alt-f27-2.ipa.local,O=Example Organization' 
  -c IPA -D 'f27-2.ipa.local' -K 'HTTP/f27-2.ipa.local@IPA.LOCAL'
New tracking request "20171121071700" added.

Then I resubmitted the tracking request. I had to include the -N option because the current Subject DN would be rejected by FreeIPA. I also had to include the -K option due to a bug in Certmonger.

[root@f27-2 ~]# getcert resubmit -i 20171121073608 
  -N 'CN=f27-2.ipa.local' 
  -K 'HTTP/f27-2.ipa.local@IPA.LOCAL'
Resubmitting "20171121073608" to "IPA".
[root@f27-2 ~]# sleep 5
[root@f27-2 ~]# getcert list -i 20171121073608 
  | egrep 'status|error|issuer|subject'
      status: MONITORING
      issuer: CN=IPA.LOCAL CA 2017.11.09
      subject: CN=f27-2.ipa.local,O=IPA.LOCAL 201711061603

The renewal succeeded, proving that certificate issuance via the FreeIPA framework is working.

Checking replica health

At this point, I’m happy with the state of the FreeIPA server. But so far I have only dealt with one server in the topology (the renewal master, whose hostname is f27-2.ipa.local). What about other CA replicas?

I log onto f27-1.ipa.local (a CA replica). As a first step I execute ipa-certupdate. This failed in the same was as on the renewal master, and the steps to resolve were the same.

Next I tell Certmonger to renew the CA certificate. This should not renew the CA certificate, only retrieve the certificate from the LDAP certificate store:

[root@f27-1 ~]# getcert list -i 20171106064548 
  | egrep 'status|error|issuer|subject'
        status: MONITORING
        issuer: CN=Certificate Authority,O=IPA.LOCAL 201711061603
        subject: CN=Certificate Authority,O=IPA.LOCAL 201711061603
[root@f27-1 ~]# getcert resubmit -i 20171106064548
Resubmitting "20171106064548" to "dogtag-ipa-ca-renew-agent".
[root@f27-1 ~]# sleep 30
[root@f27-1 ~]# getcert list -i 20171106064548 | egrep 'status|error|issuer|subject'
        status: MONITORING
        issuer: CN=Certificate Authority,O=IPA.LOCAL 201711061603
        subject: CN=Certificate Authority,O=IPA.LOCAL 201711061603

Well, that did not work. Instead of retrieving the new CA certificate from LDAP, the CA replica issued a new certificate:

[root@f27-1 ~]# certutil -d /etc/pki/pki-tomcat/alias -L 
    -n 'caSigningCert cert-pki-ca'
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 268369927 (0xfff0007)
        Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
        Issuer: "CN=Certificate Authority,O=IPA.LOCAL 201711061603"
        Validity:
            Not Before: Tue Nov 21 08:18:09 2017
            Not After : Fri Nov 06 06:26:21 2037
        Subject: "CN=Certificate Authority,O=IPA.LOCAL 201711061603"
        ...

This was caused by the first problem we faced when renewing the CA certificate with a new Subject DN. Once again, a mismatch between the Subject DN in the CSR and the FreeIPA CA’s Subject DN has confused the renewal helper.

The resolution in this case is to delete all the certificates with nickname caSigningCert cert-pki-ca or IPA.LOCAl IPA CA from Dogtag’s NSSDB then add the new CA certificate to the NSSDB. Then run ipa-certupdate again. Dogtag must not be running during this process:

[root@f27-1 ~]# systemctl stop pki-tomcatd@pki-tomcat
[root@f27-1 ~]# cd /etc/pki/pki-tomcat/alias
[root@f27-1 ~]# certutil -d . -D -n 'caSigningCert cert-pki-ca'
[root@f27-1 ~]# certutil -d . -D -n 'caSigningCert cert-pki-ca'
[root@f27-1 ~]# certutil -d . -D -n 'caSigningCert cert-pki-ca'
[root@f27-1 ~]# certutil -d . -D -n 'caSigningCert cert-pki-ca'
certutil: could not find certificate named "caSigningCert cert-pki-ca": SEC_ERROR_BAD_DATABASE: security library: bad database.
[root@f27-1 ~]# certutil -d . -D -n 'IPA.LOCAL IPA CA'
[root@f27-1 ~]# certutil -d . -D -n 'IPA.LOCAL IPA CA'
[root@f27-1 ~]# certutil -d . -D -n 'IPA.LOCAL IPA CA'
certutil: could not find certificate named "IPA.LOCAL IPA CA": SEC_ERROR_BAD_DATABASE: security library: bad database.
[root@f27-1 ~]# certutil -d . -A 
    -n 'caSigningCert cert-pki-ca' -t 'CT,C,C' < /root/ipa-ca.pem
[root@f27-1 ~]# ipa-certupdate
trying https://f27-1.ipa.local/ipa/json
[try 1]: Forwarding 'ca_is_enabled' to json server 'https://f27-1.ipa.local/ipa/json'
[try 1]: Forwarding 'ca_find/1' to json server 'https://f27-1.ipa.local/ipa/json'
Systemwide CA database updated.
Systemwide CA database updated.
The ipa-certupdate command was successful
[root@f27-1 ~]# systemctl start pki-tomcatd@pki-tomcat

Dogtag started without issue and I was able to issue a certificate via the ipa cert-request command on this replica.

Discussion

It took a while and required a lot of manual effort, but I reached the goal of changing the CA Subject DN. The deployment seems to be operational, although my testing was not exhaustive and there may be breakage that I did not find.

One of the goals was to define the process for both self-signed and externally-signed CAs. I did not deal with the externally-signed CA case. This article (and the process of writing it) was long enough without it! But much of the process, and problems encountered, will be the same.

There are some important concerns and caveats to be aware of.

First, CRLs generated after the Subject DN change may be bogus. They will be issued by the new CA but will contain serial numbers of revoked certificates that were issued by the old CA. Such assertions are invalid but not harmful in practice because those serial numbers will never be reused with the new CA. This is an implementation detail of Dogtag and not true in general.

But there is a bigger problem related to CRLs. After the CA name change, the old CA will never issue another CRL. This means that revoked certificates with the old Issuer DN will never again appear on a CRL issued by the old CA. Worse, the Dogtag OCSP responder errors when you query the status of a certificate with the old Issuer DN. In sum, this means that there is no way for Dogtag to revoke a certificate with the old Issuer DN. Because many systems "fail open" in the event of missing or invalid CRLs or OCSP errors, this is a potentially severe security issue.

Changing a FreeIPA installation’s CA Subject DN, whether by the procedure outlined in this post or by any other, is unsupported. If you try to do it and break your installation, we (the FreeIPA team) may try to help you recover, to a point. But we can’t guarantee anything. Here be dragons and all that.

If you think you need to change your CA Subject DN and have not read the previous post on this topic, please go and read it. It proposes some alternatives that, if applicable, avoid the messy process and security issues detailed here. Despite showing you how to change a FreeIPA installation’s CA Subject DN, my advice remains: don’t do it. I hope you will heed it.

Powered by WPeMatico

Share Button

Stephen Smoogen: Presents for System Administrators: Updated nagios/nagios-plugins/nrpe

Share Button


It is the traditional US Thanksgiving time period, and I am thankful for the patience many sysadmins have had with me. After some delays updated packages for nagios, nagios-plugins, and nrpe have been made for the EPEL-6, EPEL-7, F25, F26, F27 and rawhide.

  1. nagios is updated to 4.3.4 in all channels. I have also fixed some issues in EL-6.
  2. nagios-plugins is built out of git with what I thought was going to be 2.2.2 this summer. I have cleaned out some old patches and added updates for it to work with compiles on rawhide. [I will have to update rawhide in December when I figure out the right maria-connector-c fix.]
  3. nrpe has been updated to 3.2.1 which was released in September. 
Currently one problem I have to deal with is that moved an entry for the nagios status file at some point in the past. It was in /var/spool/nagios/ and looks to be in /var/log/nagios now which various configs might not have changed to.

Otherwise please look for the updates in the various updates channels and give feedback on what you find right or wrong.

Powered by WPeMatico

Share Button

Suzanne Hillman (Outreachy): Visual Design: how does one learn it?

Share Button

A lot of companies out there seem to want UX visual design skills more than they want UX research skills. I’ve often felt like I’m missing something important and useful by not having a strong grounding in visual design, and have been searching far and wide for some ideas of how to learn it.

One of the more interesting suggestions I have had relates to typography: many websites have typography and grid principles incorporated into them, so that is a good place to start. I’ve also had a number of suggestions to just make things, with pointers to where to get ideas of what to make. Below are the suggestions that make the most sense to me.

Typography to start?

A helpful fellow volunteer (Tezzica at Behance and other places — trained in graphic design with a UX aspect at MassArt) at the UX Fair offered me a number of useful ideas, including the strong recommendation that I read the book called “Thinking With Type”, by Ellen Lupton. This books is, if nothing else, a very entertaining introduction to the various types and type families. There is the history of various fonts and types, descriptions of the pieces of a piece of type, and examples both good and bad (she calls the latter “type crimes” and explains why they are type crimes). I’m only 1/3 of the way through it, so I’m sure there’s a lot more to it.

Tezzica also suggested that I take the SkillShare course by the same author, Typography that Works. Given that I currently have free access, I am in fact doing that. Some of what we’ve covered, I knew from previous courses (grids, mostly), and some recapped a bit of what I’ve read in the book thus far. Reminders and different types of media are really useful.

I’m unexpectedly bemused by the current section, in which we are to start designing a business card. While I found the ‘business card’ size in Inkscape, I’m not completely sure that I’m managing to understand how to make the text do what I want it to do. I suspect that a lot of visual/graphic design is in figuring out how to make the tools do what you want, and then developing a better feel for ‘good’ vs ‘bad’ with practice! (I’m currently playing with Gravit Designer, which is a great deal easier to use while still being vector graphics.)

I’ve also had a chat with one of the folks I interviewed about getting a job in Boston, Sam, who had gotten a job between me talking to him and interviewing him. He also strongly suggested typography, and seems to have already worked through a lot of the problems I’m struggling with: not a lot of understanding of how visual design works, but a strong pull toward figuring it out.

Another thing that Tezzica mentioned was assignments she’d had in school where basically they had to play around with type. In one, the challenge was to make a bunch of graphics which were basically combining letters of two different typefaces into a single thing, or a ‘combined letterform’.

What do graphic design students do?

Tezzica suggested that it would be useful to peruse Behance for students of RISD and MassArt and see where the samples look similar, and potentially identify the assignments from classes at those schools. I have thus far not been successful in this particular endeavor.

Another possible way to find assignments is to peruse tumblr or pintrest and see if any old assignments or class schedules are still there. Also thus far unsuccessful!

Both Tezzica and Sam suggested doing daily challenges (on Behance, since the accounts there don’t require someone else to invite you) using ideas from dailyui.co or dribble. Tezzica also suggested taking a look at common challenge solutions and seeing if there’s an interesting and different way to do it. Tezzica also pointed out the sharpen.design website and its randomized design prompts.

Sam suggested taking a website that I like the look of, and trying to replicate it in my favorite graphic design tool (this will probably end up being Inkscape, even though it’s not as user-friendly as I’d like), and pointed out that it could go onto my portfolio with an explanation of what I was thinking while I did it.

Coursework

Tezzica suggested a Hand Lettering course by Timothy Goodman and a Just Make Stuff course by him and Jessica Walsh (this one being largely about ‘making something already’). She also suggested Nicholas Felton’s Data Visualization courses (introduction to data visualization, and designing with processing). Both are on Skillshare.

Sam suggested I watch everything I can from John McWade on Lynda.com, and a graphic design foundations: typography course also on lynda.com.

Other training methods

Finally, Sam recommended taking screenshots and making notes of what I notice about sites that are interesting or effective and why.

This reminds me a bit of my periodic intent to notice what design patterns and informational architecture categorization methods websites use.

Mostly, I need to train my eye and my hand, both of which require practice. Focused practice, and I think between Sam and Tazzica, I have a good sense of where to go with it. At the moment, I’m focusing on the Thinking With Type book and course, as otherwise I’ll overwhelm myself.

Powered by WPeMatico

Share Button

mythcat: Fedora 27 : load81 simple lua game engine .

Share Button


Today I tested something simple with Fedora 27 and scheduling in.
This is a SDL based Lua programming environment for children called load81.

The author teel us:

The name Load81 originates from the fact that in popular Commodore home computers the command LOAD “*”,8,1 would load the first program on the disk starting from the file-specified memory location.

Load81 is written in ANSI C and uses SDL and SDL_gfx and SDL_image libraries.
I installed all these libraries and everything worked very well.
Once taken from github with clones I tested the examples in the examples folder and worked well from the first time.
The examples folder come with simple examples and some simple games.
Create your lua script and use this command to run it:

./load81 example.lua

All running scripts require a graphical display account.
They worked very well on my normal account and I got a run-time error on my root account.
From examples, I took the triangles.lua script to illustrate how this game engine looks and works.


function setup()
background(0,0,0);
end

function draw()
fill(math.random(255),math.random(255),math.random(255),math.random())
triangle(math.random(WIDTH),math.random(HEIGHT),
math.random(WIDTH),math.random(HEIGHT),
math.random(WIDTH),math.random(HEIGHT))
end

This is screenshot of triangles.lua script:

Powered by WPeMatico

Share Button

Open Source Security Podcast: Episode 71 – GitHub's Security Scanner

Share Button

Josh and Kurt talk about GitHub’s security scanner and Linus’ security email. We clarify the esoteric difference between security bugs and non security bugs.

Show Notes

Powered by WPeMatico

Share Button

Julita Inca Chiroque: Parallel Computing Talk

Share Button

As it was announced, a talk regarded Parallel Computing had been included in the Anniversary event of the Faculty of System Engineering, called SETEIS.It was an hour and a half talk to introduce students into the Parallel Computing world. It was a considerable audience interested in the topic.I started by explaining the serial computing and then introduced them finally get into the Parallel computing examples, taxonomy, architectures, ways to execute, programming languages and more APIs related.

As it is usual, I prized people who responded Parallelism and computers questions properly. I did a question regarded to supercomputers in parallel.

Thanks to the local UNTELS team, and to CEIS UNTELS for the invitation! ❤

Filed under: Education, Events, FEDORA, GNOME Tagged: computing, fedora, Fedora + GNOME community, Julita Inca, Julita Inca Chiroque, linux, Parallel, Parallel computing, Semana UNTELS, SETEIS, UNTELS

Powered by WPeMatico

Share Button

Alberto Rodriguez (A.K.A bt0): Cisco Packettracer 7.1 on Fedora 27

Share Button

Cisco Packet Tracer 7.1 is created by Cisco SystemsTM and is now provided for free distribution. Self learners are now able to download Cisco Packet Tracer after registering on Cisco Netacad website. A free Packet Tracer 101 (English), a 1-hour self-paced online course is also offered to every registered (free) student to help them get started with PacketTracer 7.1.  So you can register and download from here.

The cisco packettracer 7.1 is available for GNU/Linux under the next requirements:

  • nss,linicu and ssl libraries.
  • QT5 script-tools, WebKit.
  • Cisco NetSpace account. (Mandatory)
  • x86_64 family processor (Cisco droped i86 support for Linux)

We need install some libraries as follows:

$ sudo dnf install zlib-devel ncurses-devel gtk2 glibc glibc-devel  \
 libpng12 libstdc++ libX11-devel libXrender libXrandr libusb \ 
 libXtst nss qt qtwebkit qt5-qtmultimedia qt5-qtwebkit

x86_64 (64bits)

Today most people have a x86_64 machine and this time we have three options for resolve the OpenSSL dependency:

1.- Just download the package generated by me and simply trust me (I call this the ugliest method because i don’t provide any warranty):

$ sudo dnf copr enable bt0dotninja/openssl-lib-compat
$ sudo dnf install openssl-lib-compat

2.- Compile your own version (I call the “just ugly” method because you can check the source):

First get the code:

$ wget http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/17/Everything/source/SRPMS/o/openssl-1.0.0i-1.fc17.src.rpm
$ sudo dnf install @development-tools fedora-packager krb5-devel
$ sudo rpm -Uvh openssl-1.0.0i-1.fc17.src.rpm

For the build process we need super user access:

$ su -
# cd rpmbuild/SPECS/
# wget http://bt0.ninja/rpm/openssl-lib-compat-1.0.0.spec
# rpmbuild -bb openssl-lib-compat-1.0.0.spec
# rpm -i ../RPMS/x86_64/openssl-lib-compat-1.0.0i-1.fc27.x86_64.rpm
# exit

So many thanks to Yves L’ECUYER owner of http://www.deltaeridani.com, the original spec and the example are all from him.

Cisco Packet Tracer 7.1 will be downloaded from Cisco Networking Academy Portal,

$ tar -xzf PacketTracer71_*_linux.tar.gz && cd PacketTracer71
$ chmod +x install
$ sudo ./install

After accept the EULA, the installation begins, we need set the environment variables with the next command:

$ sudo chmod +x /opt/pt/set_ptenv.sh
$ sudo /opt/pt/set_ptenv.sh
$ sudo chmod +x /opt/pt/set_qtenv.sh
$ sudo /opt/pt/set_qtenv.sh

And finally fixing some missing dependencies (Many thanks to Robertpro for this fix )

# As user...
mkdir ~/.lib64
wget https://github.com/robertpro/tips/raw/59d14e7b148ebd10698ad3621b4c8a0bad38844b/packet_tracer_fedora26/libicudata.so.52 -O ~/.lib64/libicudata.so.52
wget https://github.com/robertpro/tips/raw/59d14e7b148ebd10698ad3621b4c8a0bad38844b/packet_tracer_fedora26/libicui18n.so.52 -O ~/.lib64/libicui18n.so.52
wget https://github.com/robertpro/tips/raw/59d14e7b148ebd10698ad3621b4c8a0bad38844b/packet_tracer_fedora26/libicuuc.so.52 -O ~/.lib64/libicuuc.so.52

# Adding new library path ONLY for the packettracer startup script 
sudo sed -i "s|lib|lib:$HOME/.lib64|g" /opt/pt/packettracer

If for some reason Robertpro stops hosting that libraries, you can download it from here.

Graphical Launcher on Gnome

With our favorite plain text editor we will edit the file /usr/share/applications/pt7.desktop as follows:

#!/usr/bin/env xdg-open
[Desktop Entry]
Name=PacketTracer 7.1 
Comment=Networking Cisco 
GenericName=PacketTracer 7.1 
Type=Application
Exec=/opt/pt/packettracer 
Icon=pt7
StartupNotify=true

Or as point me the always clever x3mboy, you can just:

$ sudo cp /opt/pt/bin/Cisco-PacketTracer.desktop /usr/share/applications/

 

Now we will run Cisco Packet Tracer 7.1 from our Desktop:

Enjoy 😛

 

Powered by WPeMatico

Share Button

mythcat: Fedora 27 : lua programming with torch and love 2d.

Share Button


The Lua programming language is a good programming tool to start and test your programming skills.
Lately, the capabilities of computers and computer networks have increased exponentially.
The programming language allows the user simple programming possibilities with essential advantages.
I will illustrate some programs and frameworks that may be of special interest to you:

  • Wireshark has an embedded Lua interpreter and you can be used to write dissectors (to decode packet data), post-dissectors and taps;
  • Torch is a scientific computing framework with wide support for machine learning algorithms;
  • Love 2D is a framework for making 2D games for windows, linux and android;

Today I start with install lua , torch and love 2D.
This work very well. If you use root accont then love command will work only with display SDL. This means you have to use a normal user, not a root user.
I used dnf install tool for lua and love 2d and github for torch.
The result can be seen in the following screenshots:

Powered by WPeMatico

Share Button