Are you seeing this behavior or you believe that is what going to happen. Honestly i have never done that myself but i think it should work.
Have a look at:
Also, whenever you make a change you should actually apply the authgroup configuration again. From user guide:
When you make a change to an authgroup, the change takes effect only after you respecify the associated authgroup in the SSL proxy service using the authgroup command.
Sometimes i see you need to bounce SSL-PROXY service itself too.
Hope this helps.
thanks for the reply. I described the real behavior. We played with the authgroups, re-applied config under ssl-proxy service and this is what we got. I have read the docs, it says we can specify up to 10 certificates (order is not important), but this does not work and I do not know, if they all must be a part od 1 chain, or it is a bug, or we understood it incorrectly and this will never work.
If you are seeing this in production then it could be a bug. I would recommend opening a TAC case for further investigation.
I will see if i can find a known issue like this. If i do i will put it here but in the meantime you can open a TAC case.
before I started this discussion, I had searched in the Bug toolkit, but have not found any similar behavior. Maybe you can find it in the internal database. Our version is A5(2.1e).
This is a shot in the dark but can you define ssl parameter and do purpose checking disable and see if that makes a difference?
By default, during server authentication of a chain of certificates, the ACE performs a purpose check on the basicContraint field for the following:
•The server certificate has a CA FALSE setting.
•The intermediate certificates have the CA TRUE setting.
If the field does not have these settings, the certificate fails authentication.
If you decide that it is unnecessary for the ACE to perform purpose checking during the authentication of the certificates, you can disable it by using the purpose-check disabled command in the parameter map SSL configuration mode.
The syntax of this command is as follows:
For example, to disable purpose checking, enter
host1/Admin(config)# parameter-map type ssl SSL_PARAMMAP_SSL
host1/Admin(config-parammap-ssl)# purpose-check disabled
To re-enable the default setting of performing a purpose checking, use the no form of the command:
host1/Admin(config-parammap-ssl)# no purpose-check disabled
Please have a looking on this link http://www.openssl.org/docs/apps/x509v3_config.html Basic Constraints. This is a multi valued extension which indicates whether a certificate is a CA certificate. The first (mandatory) name is CA followed by TRUE or FALSE.. If CA is TRUE then an optional pathlen name followed by an non-negative value can be included. For example: basicConstraints=CA:TRUE basicConstraints=CA:FALSE basicConstraints=critical,CA:TRUE, pathlen:0 A CA certificate must include the basicConstraints value with the CA field set to TRUE. An end user certificate must either set CA to FALSE or exclude the extension entirely. Some software may require the inclusion of basicConstraints with CA set to FALSE for end entity certificates. The pathlen parameter indicates the maximum number of CAs<http://www.openssl.org/docs/apps/x509v3_config.html> that can appear below this one in a chain. So if you have a CA with a pathlen of zero it can only be used to sign end user certificates and not further CAs.
Let me know how it goes.
unfortunately, it did not help. The behavior is the same after we applied "purpose-check disabled". Do you have any other suggestions?
One mistake on my side, it is ACE4710 with A5(2.1), not ACE30, I do not know if it plays the role, but sorry for the confusion anyway.
thanks, we opened a TAC case, and it is a bug CSCtg00135. Unfortunately, this bug is hidden in the database so I could not find it.
Thank you for your help.
Thank you for the information. I should have found it but may be keywords used were not a hit:)
Have a good day.