Hi, We're trying to get automated enrollment going with a new dogtag CA (v.9 auf RHEL6) using SCEP. We have a system in place which verifies signing requests (assuming the role of an RA) and would pass them on to the CA using the SCEP protocol. We have problems trying to achieve a configuration with which we can live with. version 9 of DT is very stringent about not allowing reuse of PINs. How do others use SCEP with thousands of clients without managing the flatfile.txt for all of the different hosts and PINs? (In the past we have used the same PIN for all hosts, route all requests over the same IP (UID) and restricted DT from commenting out the entry in flatfile.txt. However, the latest versions of DT seem to cache the status of UID/PIN from the flatfile in memory as already used and invalid after it is used once. When I read the documentation of CS 8.1 regarding router certificates, I'm amazed by the tedious manual steps involved with authentication. How can this be used with thousands of clients? I'd like to have the CA authenticate the SCEP requests based on a the pkcs7 signature - that being one using a valid cert from the CA (similar to renewal in the protocol, without the PIN.) I tried this with and without a PIN in the pkcs10 request, but it also failed unless a valid PIN was in the flatfile.txt file. Authentication seems always to require a valid (one-time) PIN. Basically, we'd like to be able to reuse PINs as before - even though this was disallowed in a security bug-fix (I don't have the bug ID at hand ). Or, I'd even grudgingly accept NO authentication, and I would restrict/control access through other means (network, etc.) I'd love to hear from anyone who has SCEP in use with many hosts! How do you achieve it these days??? Thanks in advance for any tips, William Elliott s IT Solutions Open System Services s IT Solutions AT Spardat GmbH mailto:william.elliott@s-itsolutions.at Head Office: Vienna Commercial Register No.: 152289f Commercial Court of Vienna This message and any attached files are confidential and intended solely for the addressee(s). Any publication, transmission or other use of the information by a person or entity other than the intended addressee is prohibited. If you receive this in error please contact the sender and delete the material. The sender does not accept liability for any errors or omissions as a result of the transmission.