Andreas, > I'm trying to test expiry notification test but I must do it wrong.
Yep. > My idea was to the the cutoff_notafter form +60 days to +1 year; > > diff --git a/config.d/realm.tpl/report/expiry.yaml > b/config.d/realm.tpl/report/expiry.yaml > index 1ab0a1b..9a2de6e 100644 > --- a/config.d/realm.tpl/report/expiry.yaml > +++ b/config.d/realm.tpl/report/expiry.yaml > @@ -1,7 +1,8 @@ > label: Expiry Report > head: "Certificate Expiry Report, created at: [% export_date %]" > delimiter: "\t" > -cutoff_notafter: +000060 > +#cutoff_notafter: +000060 > +cutoff_notafter: +01 > include_expired: -000030 > cols: You changed the reporting interval for the reports that can be generated interactively from the GUI. This does not affect the expiry notification workflow. > and ran: > > # openxpkicmd --realm democa notify_expiry > > But "Certificate Status Summary" in WebUI reports 0 certificates near > expiration and emails are sent. > > I also don't quite understand the sign of parameter cutoff_notafter and > included_expired. I thought, certificates with notafter > now - 60 days are > considered as near expiration and all certifcates with notafter > now + 30 > days are included but the signs are "+" for cutoff_notafter and "-" for > included_expired. > > What I'm missing here? How can certificates with let's say 11 months lifetime > left be considered as near expiration? In the Community Edition's notify_expiry workflow, the default for triggering expiry notifications is 30 days before expiration. It is possible to change this when triggering the workflow on the command line by specifying a different threshold in the parameter cutoff_notafter (must be a relative OpenXPKI date). However, the capabilities of the Expiry Notification workflow in the Community Edition are very limited compared to the Enterprise Edition. In the Enterprise Edition it is possible to define ascending levels of severity with their own thresholds (e. g. 90, 30, 10 days before expiration), and the Enterprise Edition also makes sure that only one notification is sent for each escalation level. You may have noticed that OpenXPKI is highly configurable but can also be quite complex if you are not familiar with the intricacies of the system. If you are interested in accelerating your OpenXPKI evaluation experience, getting in touch with White Rabbit Security could be worth a thought. Cheers Martin _______________________________________________ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
