One way to learn a new technology is to compare it to what you already know. I’ve heard a lot about Istio, and I don’t really grok it yet, so this post is my attempt to get the ideas solid in my own head, and to spur conversations out there.
When you enroll CloudForms with an IdM Server, you do not automatically get the HTTPS certificates from that server. It takes a deliberate additional step to do so.
While trying to debug an Ansible module calling Certmonger, I found myself afoul of some mistake I could not quite trace. Certmonger was having trouble reading the key to generate the certificate. But nothing was showing up in the log. Here’s how I got some logging info.
Now that I know that I can do things like read the Keys from a Programmatic registered provider and properly set up SELinux to deal with it, I want to see if I can make this work for a pre-compiled application, using only environment variables.
Earlier this week, I got some advice from John Dennis on how to set up the certificates for a Java based web application. The certificates were to be issued by the Dogtag instance in a Red Hat Identity Mangement (RH IdM) install. However, unlike the previous examples I’ve seen, this one did some transforms from the certificate files, into PKCS12 and then finally into the keystore. It Looks like this:
ipa-getcert request -f /etc/pki/tls/certs/rhsso-cert.pem -k /etc/pki/tls/private/rhsso-key.pem -I rhsso -K RHSSO/`hostname` -D `hostname` openssl pkcs12 -export -name rhsso -passout pass:FreeIPA4All -in /etc/pki/tls/certs/rhsso-cert.pem -inkey /etc/pki/tls/private/rhsso-key.pem -out rhsso.p12 keytool -importkeystore -srckeystore rhsso.p12 -srcstoretype PKCS12 -srcstorepass FreeIPA4All -destkeystore keycloak.jks -deststorepass FreeIPA4All -alias rhsso keytool -keystore keycloak.jks -import -file /etc/ipa/ca.crt -alias ipa-ca cp keycloak.jks /etc/opt/rh/rh-sso7/keycloak/standalone/
Aside from the complications of this process, it also means that the application will not be updated when Certmonger automatically renews the certificate, leading to potential down time. I wonder if there is a better option.
PKI tokens in Keystone suffered from many things, most essentially the trials due to the various forms of revocation. I never wanted revocation in the first place. What could we have done differently? It just (I mean moments ago) came to me.
Port 8080 is a popular port. Tomcat uses it as the default port for unencrypted traffic. FreeIA, installs Dogtag which runs in Tomcat. Swift proxy also chose that port number for its traffic. This means that if one is run on that port, the other cannot. Of the two, it is easier to change FreeIPA, as the port is only used for internal traffic, where as Swift’s port is in the service catalog and the documentation.
Certmonger is split into 3 parts
- getcert or comparable helper app which the user calls to make requests. The request is put on dbus and and sent to
- The certmonger binary. This reads the request off of dbus and makes a call to
- The help application which makes calls to the remote service.
Debugging this process is much easier if you run the certmonger service from the command line and tell it to log debugging output. Make sure no certmonger-session processes are running: