Today we’re pleased to release a new management API for CertFu, our ACME-enabled, private certificate authority.

This is in addition, of course, to the ACME API, which remains the standard interface for ACME-compatible clients.

This new management API is for use outside ACME clients, such as for automated provisioning and auditing. The API covers:

• EAB tokens (external account bindings) and ACME client account keys, for automated provisioning of ACME clients that need certs.
• Directories and CA certs, for automated provisioning of your private CA infrastructure itself.
• Orders and Issued certs, for reviewing and auditing cert issuance across your infrastructure.

All told, this makes it easier than ever to integrate a private CA with the rest of your infrastructure.

More information on the management API can be found in the CertFu API docs.

As always, don’t hesitate to reach out if you have questions about the CertFu API or anything else!

Two updates today for DNScaster.

First, we’ve added a new Clone feature for IP Monitors and Boundaries. This parallels similar functionality already available for Hosts and makes quick work of creating new Monitors or Boundaries that are substantially similar to existing ones.

Second, several API resources now sport a new field, properties, suitable for storing per-record metadata as key/value pairs.

This succeeds the prior external_ref field which is now deprecated. Whereas external_ref stored only a single value, properties allows multiple key/value pairs making it much more flexible and perfect for storing data related to the integration of DNScaster with your other infrastructure.

APIs for listing resources, such as List Zones, may also now filter based on properties.

To learn more, see the Properties API docs.

We’ve been making a number of updates to the Cosmic management portal lately. Let’s go over those.

First up, accounts may now have multiple owners. Previously, only one owner was allowed and it required a support ticket to change owners. Now, any owner may add or remove other owners. This should be much more flexible for businesses when dealing with employee changes and even role account changes.

Next, team members on an account are now able to remove themselves. Before, only an admin could remove a team member. That’s still usually going to be the case, but sometimes it’s just easier for someone to remove themselves and now they can.

Continuing on the theme of streamlined account management, an account owner may now close an account. Like above, this too previously required contacting support. Be sure to download any invoices first as the entire account will immediately become inaccessible once closed.

Closely related to closing accounts is canceling an unneeded login profile. This, too, can now be performed directly. All associated accounts must be left or closed first.

Lastly, users may now view all of their active login sessions and logout any particular session. We hope you never need this, but it’s there if you do.

Today we’re announcing the addition of a Remember me feature to LoginRocket.

In our implementation, users may select to have their email or username remembered for future logins. Remembered emails/usernames are stored entirely client-side and prepopulated on the next visit to the login form. This does not remember passwords or otherwise affect the configured session lifetimes.

Since this may not be wanted for all apps, it is an opt-in feature and may be found at Settings -> LoginRocket -> Other features -> Logins.

We’ve also enabled the same for logins to Cosmic’s management portal.

It’s been a while since we’ve added an entirely new event type within AuthRocket, but today is that day. We’re pleased to make available the new session.deleted event.

As you might guess from the name, session.deleted is sent when a Session is deleted before its expiration time. Since Sessions and JWTs already include an expiration time, session.deleted is not sent upon or after Session expiry.

This greatly improves the ability to cache sessions as now a webhook for session.deleted can be used to prematurely expire the cached copy.

Similarly, for apps relying solely on issued JWTs, this new webhook can be used to populate the app’s list of invalidated sessions. To help maintain such a list, the webhook payload will include the original expiration time. This bridges the gap until the session would have expired anyway.

Related, session.deleted is now triggered for all outstanding sessions upon a successful password reset or administrative password change.

Finally, sessions may now be optionally deleted upon a user-initiated password change with the new keep_sessions argument. The default value is all which preserves existing API behavior. LoginRocket now deletes all sessions except the one being used to perform the password change.