That's interesting. What "Key Usage" is listed in your Juniper Admin now (Configuration > Trusted Client CAs) ? Our's is : Key Usage: Certificate Sign, CRL Sign Maybe Juniper can tell us more about what is actually needed now for successful client certificate authorization ? Because it's all like trial-and-error sience since they changed the behavior with the firmware upgrade. ... View more

Unfortunately I have no experience with Win-CA-Server (we use Linux OpenSSL). But as what I can read in the web, I think you should preset BasicConstraints for your client certificates in the "CAPolicy.inf" file. (Section "[basicconstraintsextension]" ?) ... View more

That is what I meant in the beginning : If you have V1 client certificate, then you do not need the BasicConstraints-Setting (because with Version 1, this field was not specified). But with V3 client certificates, the BasicConstratints-Setting is a must-have. So you need to set your Windows-CA-Server to set this field for the client certificates when you issue them. ... View more

I think with your Windows CA Server you need to set : Basic Constraints Subject Type =CA Length Constraint=None Because if you set it to subject "End Entity" it can not validate your client certiciates. (see http://technet.microsoft.com/en-us/library/cc875810.aspx) " Note: The presence of the Basic Constraints subject type is very important. This value distinguishes a CA certificate from an end entity certificate. " ... View more

At least for us we had to re-issue our self-signed server certificate. This time with Basic Constraints setting. We then of course had to re-issue all client certificates aswell. We however did not set the Basic Constratints setting with the Client certificates. We did it only with the server side one. In Juniper-Admin-GUI the server side certificate now shows : Version: 3 Basic Constraints: CA:TRUE Whereas our "old" server side certifcate showed only : Version: 1 Our client certificates still show version 1. Maybe this is the reason why it does not work on your side ? I think if you have version 3 client certificates then you also would need to set "Basic constratints" with the client certificates. (This time with "CA:FALSE", of course). ... View more

Dear zanyterp_, it indeed seems that our certificate is no longer working because we miss "Basic Constraits". Now the question : Do we really need to re-issue our certificate and thereby have to replace all our client certificates aswell ? This would mean a lot of unneccessary work for us. Or is there an other way ? ... View more

>What do you role map against? Based on usernames. As last position (when username is no "special" one) then user gets a standard role. >What does your policy trace show? Nothing. It seems it never gets to that point. You open the browser. At the first time accessing it opens list of your certificates. You choose it and Juniper then says the certification is wrong or invalid. In Juniper log there only is one line in the logs, which says "WrongCert". This is very curious for us. Because we in the past installed some upgrades already and there never occured a problem nor did we changed our certificate since that. Our upgrade path was 5.4R6->6.4R4.1->7.0R1->7.0R4 These upgrades did not worked for us : 7.1R2.0, 7.1R1.0, 7.0R6.0, 7.0R5.1 So 7.0R5.1 is the first upgrade after our current version. What has changed in 7.0R5.1 regarding certificates ? ... View more

Under "Configuration > Certificates > Trusted Client CAs" we have the self-signed certificate. "Client certificate status checking" is set to "None". Checks are on "Trusted for Client Authentication" and "Participate..." As an Auth. Server, we put up type "Certificate Server". User mapping via default setting "<certDN.CN>". Under User Realm for Authentication above Certificate Server it set. Under Authentication Policy/Certificate it is set : "Only allow users with a client-side certificate signed by Trusted Client CAs to sign in. To change the certification authority, see the Trusted Client CA page." That's it. No more settings. ... View more

Not sure how to send priv-message here, but we do not have a case number anyway. ... View more

We do not have any other check. And CRL, etc.. is disabled. ... View more

Hopefully they can find the problem. Our clients are asking for Firefox 4 Support all the time now and we are unable to upgrade to 7.1R2 :-( ... View more

We currently use 7.0R4_ with Self-signed certificate for client auth. We tried to upgrade to 7.1R2.0 and out of nowhere it is not possible to log-in anymore. We only get "WrongCert" error in the log. We re-imported the TrustedClient-CA and there is no error. We rolled-back to 7.0R4 and instantly login worked again. Then we tried 7.1R1.0 with same result. Roll-Back. We tried 7.0R6.0 : Same result, roll back. We tried 7.0R5.1 : Same result, roll back. We checked all settings. Added new auth server and realms, compared all settings. Imported settings+certs from backup. But nothing. We are really cluless here. Maybe someone can solve the riddle ? ... View more