Beyond who is allowed to sign in, Skyrsoft CertOps has a separate set of controls over where a sign-in attempt is allowed to come from at all: a management IP allowlist that can confine the console to trusted networks while the public PKI protocols stay reachable from anywhere, a persistent block list for addresses that fail sign-in repeatedly, configurable password and session policy, and a way to tell the server which reverse proxy in front of it to trust.
How it works
Each control lives under Settings → Security and takes effect immediately — none of them need a service restart. They are also independent of each other by design: the allowlist decides whether an address may reach the console at all, the rate limiter and block list decide what happens to an address that is reaching it and failing, and password policy and session timeout govern the account once it’s in.
Sign-in rate limiting and the IP block list
Two brakes sit in front of /auth/login, and neither replaces the other. A fixed-window rate
limit — 10 attempts per minute per client address by default — caps how fast an address can
guess; it keeps no record and resets every minute. Sustained failure past that triggers the
persistent block list, which refuses the address outright, survives a service restart, and is
visible and removable from Settings → Security. The defaults are generous enough that a real user
mistyping a password, or a shared office address where several people fumble the login at once,
never trips it: 20 failed sign-ins inside 15 minutes earns a 15-minute block. The two brakes
interact in a way worth knowing before you test them: the rate limiter sits in front of the block
counter, so a fast burst of failures gets rate-limited before it ever reaches the counter that
decides a block. The block is a brake on sustained, paced failure across more than one rate-limit
window, not on a single rapid burst.
A manual block or unblock is also available, independent of the automatic thresholds — turning the automatic threshold off is a different decision from lifting blocks already in place. Neither brake ever blocks the address you are currently connected from, and loopback is never blocked automatically, so a session on the server’s own console can’t be locked out by its own rate limiting.
Management IP allowlist
Where the console is published to the internet behind a reverse proxy, the management IP allowlist restricts sign-in and the admin console to trusted networks — an office IP, a VPN range, an internal LAN — while the public PKI protocol endpoints (CRL, OCSP, ACME, EST, SCEP, the REST API, agent traffic) stay reachable from anywhere. It is a categorically sharper tool than the block list: a block list denies only misbehaving addresses, while an allowlist denies everyone by default the moment it is switched on, so three safety rails apply. Saving a list that does not cover the address you are currently connected from is refused outright, so enabling it can’t lock you out from the browser you’re using to enable it. An allowlist saved as enabled with no entries at all fails open rather than refusing every connection. And loopback access — a session on the server itself, over RDP or a physical console — is never subject to the allowlist at all; there is no field to put it in and nothing to misconfigure, because the check runs before the configured list is even consulted.
Password policy
Minimum password length, and whether an uppercase letter, a lowercase letter, a digit or a symbol is required, are all configurable; the only fixed floor is that a password is required at all. Every path that sets a password — creating a user, an administrator resetting one, and a user changing their own — enforces the same policy from the same place, so the rule can’t drift between those three actions the way a rule copied to each call site eventually does.
Session timeout
How long a signed-in session stays valid is configurable, independently of password policy, from a few minutes up to a week.
Trusting a reverse proxy’s forwarded headers
Everything above keys off the client address CertOps sees on the connection. Behind a reverse proxy or WAF, that address is the proxy’s own unless you tell CertOps which proxy to trust — done from Settings → Security by naming the proxy’s address or network, with no file to edit and no restart required. This is deliberately off, and trusts nothing, until a proxy is named: the headers it reads come from the caller, so honouring them unconditionally would let anyone reaching the listener directly forge a source address into the audit log and past both brakes above.
Limits
Behind an unconfigured proxy, every one of the controls above collapses onto one address. If forwarded headers aren’t configured, every sign-in attempt through the proxy appears to come from the same place — the rate limiter becomes a single global bucket an attacker can exhaust to lock out every legitimate user, and a block or an allowlist entry keyed to the wrong address does nothing useful. Configure proxy trust before relying on any address-based control.
A wrong proxy entry fails silently. An unlisted proxy’s headers are discarded rather than rejected with an error, so client addresses keep reading as the proxy with no indication anything is misconfigured beyond the addresses themselves looking wrong.
The session cookie’s Secure flag follows the request, not an unconditional requirement. It is set on an HTTPS request and not on a plain HTTP one, rather than being forced on regardless — in practice this is covered by the console’s own HTTP-to-HTTPS redirect, but it is not the same guarantee as a cookie that refuses to be sent over HTTP under any circumstance.
The management IP allowlist and the IP block list don’t cover the same surface as each other. Both exempt the public PKI protocol endpoints and agent traffic, which authenticate themselves a different way and have to stay reachable from anywhere for the server to do its job — neither control is a substitute for a firewall rule if you need to restrict those too.