Konstantin Khrooschev wrote:
dalini wrote:
Konstantin Khrooschev wrote:
Oct 22 15:56:46.149 MSD: CRYPTO_PKI: status = 100: certificate is granted
Oct 22 15:56:53.232 MSD: crypto_certc_pkcs7_extract_certs failed (1795):
Oct 22 15:56:53.232 MSD: crypto_certc_pkcs7_extract_certs failed
after "Certificate enrollment failed", only ca certificate shown.
hmm this is strange, this shouldn't happen,
can be small ram space the reason of problem ?could be, how much rum does your device have, but i think this shouldn't remove the ra-cert
maybe someone can 'sponsor' for a limited timeperiod, lets say two weeks or something an ios system so could run some tests and maybe debug the scep-code... since i developed and tested only with cisco pix equipment and sscep and therefore can't make sure assumtions about problems with iox expecially which problems to those trustpoints (i think this is a newer ios feature - or?)
i don't have anylonger access to the internal-cisco-knowledgedatabase, does someone have access to the cisco internal help-database, since the public knowledgebase is quite reduced and you get only full access to all documentation, faqs and problemsolutions with such an login ;), so i one have, he may be so kind so look for the cited error messages... maybe there are some hints what could be wrong
there is another option to, maybe you can enable more debugging output, but thats not so importend, what would be importend, to trace the problem would be, to capture the messages, while send between the router and the scep-interface
but since we don't know the router keys, we can't decrypt the captured pkcs#7 to trace this, but with higher debugging at the route (i don't know if this is possible) it may be possible to see the package data at the router and where exactly he fails, but we can see how large the outer pkcs#7 container is, since for an certificate of a certain size (like 1024 or 2048 bit) the message has to have to be around some bytes long ;)
as far as i can see from the output, the outer pkcs#7 can be read, since the router shows the status of the answer (success) - only when he tries to decrypt the encrypted part it fails and stops processing the answer
this means either the inner pkcs#7 is not encrypted with the right public key or there is nothing in or the keyinfo doesn't match, so how does the issued cert looks like?
if i think about it, there may be another option, it could be a similar problem like the one with firewall-1 systems... when the sending cert (from the client/router) changes during the transaction, and we use at the scep-interface the cert of the first request of this transaction and encrypt with that (old) one instead of the one recived during the last request
but this is all very hyptothetical since i can't verify this on my own ;(
greetings dalini
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Openca-Users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-users
