EJBCA, JEE PKI Certificate Authority

Hi Ramesh,

To install your new certificate in JBoss you have to edit
JBOSS_HOME/server/default/deploy/jboss-web.deployer/server.xml and 
add/edit the ssl and keystore entries to point to your new keystore and 
use the new password.
If TESTEJBCA.jks is issued from the same CA as your superadmin keystore 
you don't have to add anything to the truststore. Otherwise you need to 
add the CA-certificate to the truststore as well. The truststore is also 
pointed to by server.xml.

Cheers,
Tomas


32567 wrote:
> Hi,
> 
> I have created a server certificate called TESTEJBCA through
> http://localhost:8080/ejbca in jobss. EJBCA has created TESTEJBCA.jks file
> and I rant ant javastrutstore.  I am new to ejbca and I have already
> instaleld AdminWeb1 in browser. How can I validate and test test the
> TESTEJBCA server certificate with JBoss. Please help me in this...
> 
> Thanks,
> Ramesh

Hi Thomas,

Thanks for your response. SuperAdmin and TESTEJBCA certificates are
generated by same CA and I ran "ant javatruststore" command. Here is the
server.xml part for trust key store. 

    <Connector port="8443" address="0.0.0.0"
         maxThreads="150" strategy="ms" maxHttpHeaderSize="8192"
         emptySessionPath="true" protocol="HTTP/1.1" SSLEnabled="true"
         scheme="https" secure="true" clientAuth="true"
         keystoreFile="${jboss.server.home.dir}/conf/keystore/keystore.jks"
         keystorePass="serverpwd" sslProtocol = "TLS" 
        
truststoreFile="${jboss.server.home.dir}/conf/keystore/truststore.jks"
truststorePass="changeit" 
         truststoreType="JKS"
         URIEncoding="ISO-8859-1" />

The password for SuerpAdmin is ejbca and TESTEJBCA is testejbca. How do we
test the TESTEJBCA is properly deployed with JBoss. Here in the XML the
password is still pointing to changeit. do I need to do anything with this.
Is there anyway I can test this with simple jsp web application or
something. Please help.Appreciate your help.

Thanks,
Ramesh



EJBCA Support wrote:
> 
> 
> Hi Ramesh,
> 
> To install your new certificate in JBoss you have to edit
> JBOSS_HOME/server/default/deploy/jboss-web.deployer/server.xml and 
> add/edit the ssl and keystore entries to point to your new keystore and 
> use the new password.
> If TESTEJBCA.jks is issued from the same CA as your superadmin keystore 
> you don't have to add anything to the truststore. Otherwise you need to 
> add the CA-certificate to the truststore as well. The truststore is also 
> pointed to by server.xml.
> 
> Cheers,
> Tomas
> 
> 
> 32567 wrote:
>> Hi,
>> 
>> I have created a server certificate called TESTEJBCA through
>> http://localhost:8080/ejbca in jobss. EJBCA has created TESTEJBCA.jks
>> file
>> and I rant ant javastrutstore.  I am new to ejbca and I have already
>> instaleld AdminWeb1 in browser. How can I validate and test test the
>> TESTEJBCA server certificate with JBoss. Please help me in this...
>> 
>> Thanks,
>> Ramesh
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ejbca-develop mailing list
> Ejbca-develop@...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 
> 

-- 
View this message in context: http://www.nabble.com/JBoss-EJBCA-Server-Certificate-Test-tp14535065p14538779.html
Sent from the EjbCA - Dev mailing list archive at Nabble.com.

Hi Ramesh,

-Change
	keystoreFile="fullpath-to-yourfile-TESTEJBCA.jks"
	keystorePass="testejbca"
-Restart JBoss
-If you are able to login with your superadmin-cert to the Admin GUI, this means that your server-cert works..

/Johan

32567 skrev:
> Hi Thomas,
>
> Thanks for your response. SuperAdmin and TESTEJBCA certificates are
> generated by same CA and I ran "ant javatruststore" command. Here is the
> server.xml part for trust key store. 
>
>     <Connector port="8443" address="0.0.0.0"
>          maxThreads="150" strategy="ms" maxHttpHeaderSize="8192"
>          emptySessionPath="true" protocol="HTTP/1.1" SSLEnabled="true"
>          scheme="https" secure="true" clientAuth="true"
>          keystoreFile="${jboss.server.home.dir}/conf/keystore/keystore.jks"
>          keystorePass="serverpwd" sslProtocol = "TLS" 
>         
> truststoreFile="${jboss.server.home.dir}/conf/keystore/truststore.jks"
> truststorePass="changeit" 
>          truststoreType="JKS"
>          URIEncoding="ISO-8859-1" />
>
> The password for SuerpAdmin is ejbca and TESTEJBCA is testejbca. How do we
> test the TESTEJBCA is properly deployed with JBoss. Here in the XML the
> password is still pointing to changeit. do I need to do anything with this.
> Is there anyway I can test this with simple jsp web application or
> something. Please help.Appreciate your help.
>
> Thanks,
> Ramesh
>
>
>
> EJBCA Support wrote:
>   
>> Hi Ramesh,
>>
>> To install your new certificate in JBoss you have to edit
>> JBOSS_HOME/server/default/deploy/jboss-web.deployer/server.xml and 
>> add/edit the ssl and keystore entries to point to your new keystore and 
>> use the new password.
>> If TESTEJBCA.jks is issued from the same CA as your superadmin keystore 
>> you don't have to add anything to the truststore. Otherwise you need to 
>> add the CA-certificate to the truststore as well. The truststore is also 
>> pointed to by server.xml.
>>
>> Cheers,
>> Tomas
>>
>>
>> 32567 wrote:
>>     
>>> Hi,
>>>
>>> I have created a server certificate called TESTEJBCA through
>>> http://localhost:8080/ejbca in jobss. EJBCA has created TESTEJBCA.jks
>>> file
>>> and I rant ant javastrutstore.  I am new to ejbca and I have already
>>> instaleld AdminWeb1 in browser. How can I validate and test test the
>>> TESTEJBCA server certificate with JBoss. Please help me in this...
>>>
>>> Thanks,
>>> Ramesh
>>>       
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejbca-develop@...
>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>
>>
>>     
>
>

Hi Johan,

Thanks a lot for your response. I created one more entry with different port
number with my server certificate entry and I am able to access Admin GUI.
Thanks a lot for all your help.

Thanks,
Ramesh

Johan Eklund wrote:
> 
> Hi Ramesh,
> 
> -Change
> 	keystoreFile="fullpath-to-yourfile-TESTEJBCA.jks"
> 	keystorePass="testejbca"
> -Restart JBoss
> -If you are able to login with your superadmin-cert to the Admin GUI, this
> means that your server-cert works..
> 
> /Johan
> 
> 32567 skrev:
>> Hi Thomas,
>>
>> Thanks for your response. SuperAdmin and TESTEJBCA certificates are
>> generated by same CA and I ran "ant javatruststore" command. Here is the
>> server.xml part for trust key store. 
>>
>>     <Connector port="8443" address="0.0.0.0"
>>          maxThreads="150" strategy="ms" maxHttpHeaderSize="8192"
>>          emptySessionPath="true" protocol="HTTP/1.1" SSLEnabled="true"
>>          scheme="https" secure="true" clientAuth="true"
>>         
>> keystoreFile="${jboss.server.home.dir}/conf/keystore/keystore.jks"
>>          keystorePass="serverpwd" sslProtocol = "TLS" 
>>         
>> truststoreFile="${jboss.server.home.dir}/conf/keystore/truststore.jks"
>> truststorePass="changeit" 
>>          truststoreType="JKS"
>>          URIEncoding="ISO-8859-1" />
>>
>> The password for SuerpAdmin is ejbca and TESTEJBCA is testejbca. How do
>> we
>> test the TESTEJBCA is properly deployed with JBoss. Here in the XML the
>> password is still pointing to changeit. do I need to do anything with
>> this.
>> Is there anyway I can test this with simple jsp web application or
>> something. Please help.Appreciate your help.
>>
>> Thanks,
>> Ramesh
>>
>>
>>
>> EJBCA Support wrote:
>>   
>>> Hi Ramesh,
>>>
>>> To install your new certificate in JBoss you have to edit
>>> JBOSS_HOME/server/default/deploy/jboss-web.deployer/server.xml and 
>>> add/edit the ssl and keystore entries to point to your new keystore and 
>>> use the new password.
>>> If TESTEJBCA.jks is issued from the same CA as your superadmin keystore 
>>> you don't have to add anything to the truststore. Otherwise you need to 
>>> add the CA-certificate to the truststore as well. The truststore is also 
>>> pointed to by server.xml.
>>>
>>> Cheers,
>>> Tomas
>>>
>>>
>>> 32567 wrote:
>>>     
>>>> Hi,
>>>>
>>>> I have created a server certificate called TESTEJBCA through
>>>> http://localhost:8080/ejbca in jobss. EJBCA has created TESTEJBCA.jks
>>>> file
>>>> and I rant ant javastrutstore.  I am new to ejbca and I have already
>>>> instaleld AdminWeb1 in browser. How can I validate and test test the
>>>> TESTEJBCA server certificate with JBoss. Please help me in this...
>>>>
>>>> Thanks,
>>>> Ramesh
>>>>       
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Ejbca-develop mailing list
>>> Ejbca-develop@...
>>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>>
>>>
>>>     
>>
>>   
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ejbca-develop mailing list
> Ejbca-develop@...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 
> 

-- 
View this message in context: http://www.nabble.com/JBoss-EJBCA-Server-Certificate-Test-tp14535065p14544111.html
Sent from the EjbCA - Dev mailing list archive at Nabble.com.

Great that you  got it running.

Off-course you should also check in your browser, view the server 
certificate, so you can see that the certificate is the ocrrect one for 
the other port.

Cheers,
Tomas
-----
PrimeKey Solutions offers a commercial EJBCA-subscription, including 
support and new extensions for EJBCA. Please see http://www.primekey.se or 
contact info@... for more information.


32567 wrote:
> Hi Johan,
> 
> Thanks a lot for your response. I created one more entry with different port
> number with my server certificate entry and I am able to access Admin GUI.
> Thanks a lot for all your help.
> 
> Thanks,
> Ramesh
> 
> Johan Eklund wrote:
>> Hi Ramesh,
>>
>> -Change
>> 	keystoreFile="fullpath-to-yourfile-TESTEJBCA.jks"
>> 	keystorePass="testejbca"
>> -Restart JBoss
>> -If you are able to login with your superadmin-cert to the Admin GUI, this
>> means that your server-cert works..
>>
>> /Johan
>>
>> 32567 skrev:
>>> Hi Thomas,
>>>
>>> Thanks for your response. SuperAdmin and TESTEJBCA certificates are
>>> generated by same CA and I ran "ant javatruststore" command. Here is the
>>> server.xml part for trust key store. 
>>>
>>>     <Connector port="8443" address="0.0.0.0"
>>>          maxThreads="150" strategy="ms" maxHttpHeaderSize="8192"
>>>          emptySessionPath="true" protocol="HTTP/1.1" SSLEnabled="true"
>>>          scheme="https" secure="true" clientAuth="true"
>>>         
>>> keystoreFile="${jboss.server.home.dir}/conf/keystore/keystore.jks"
>>>          keystorePass="serverpwd" sslProtocol = "TLS" 
>>>         
>>> truststoreFile="${jboss.server.home.dir}/conf/keystore/truststore.jks"
>>> truststorePass="changeit" 
>>>          truststoreType="JKS"
>>>          URIEncoding="ISO-8859-1" />
>>>
>>> The password for SuerpAdmin is ejbca and TESTEJBCA is testejbca. How do
>>> we
>>> test the TESTEJBCA is properly deployed with JBoss. Here in the XML the
>>> password is still pointing to changeit. do I need to do anything with
>>> this.
>>> Is there anyway I can test this with simple jsp web application or
>>> something. Please help.Appreciate your help.
>>>
>>> Thanks,
>>> Ramesh
>>>
>>>
>>>
>>> EJBCA Support wrote:
>>>   
>>>> Hi Ramesh,
>>>>
>>>> To install your new certificate in JBoss you have to edit
>>>> JBOSS_HOME/server/default/deploy/jboss-web.deployer/server.xml and 
>>>> add/edit the ssl and keystore entries to point to your new keystore and 
>>>> use the new password.
>>>> If TESTEJBCA.jks is issued from the same CA as your superadmin keystore 
>>>> you don't have to add anything to the truststore. Otherwise you need to 
>>>> add the CA-certificate to the truststore as well. The truststore is also 
>>>> pointed to by server.xml.
>>>>
>>>> Cheers,
>>>> Tomas
>>>>
>>>>
>>>> 32567 wrote:
>>>>     
>>>>> Hi,
>>>>>
>>>>> I have created a server certificate called TESTEJBCA through
>>>>> http://localhost:8080/ejbca in jobss. EJBCA has created TESTEJBCA.jks
>>>>> file
>>>>> and I rant ant javastrutstore.  I am new to ejbca and I have already
>>>>> instaleld AdminWeb1 in browser. How can I validate and test test the
>>>>> TESTEJBCA server certificate with JBoss. Please help me in this...
>>>>>
>>>>> Thanks,
>>>>> Ramesh
>>>>>       
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> Ejbca-develop mailing list
>>>> Ejbca-develop@...
>>>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>>>
>>>>
>>>>     
>>>   
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejbca-develop@...
>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>
>>
>

Hi Francicso,

I'm not 100% sure I understood your idea, but I'm imagining the 
following use-case:

1. Someone sends a certificate to an EJBCA installation through WS
2. If internal issuer → validate directly by EJBCA
If external issuer and issuer is in a list of approved issuers → let 
EJBCA fetch CRL and validate cert
3. Return result

This would be a great service, but wouldn't it be better suited as a 
separate/addon application (that may or may not be deployed in the same 
app-server)? That way it could be made more general and configurable to 
not allow incoming traffic to the CA by pushing EJBCA CRLs to the 
verification service..

1. Recieve WS
2. Check if issuer is approved by consulting local database
3. Check (cached/pushed) CRL in database or OCSP depending on content of 
certificate
4. Return response

And maybe it would be nice to have the entire CA-certificates base-64 
encoded in the database and the subjectDN to search for..

Just some ideas,
Johan

Francisco Sepulveda skrev:
> Hello guys
>
> I'm designing a PKI module wich i want to build using EJBCA for 
> generating the certificates and the Apache-XML-Security API for 
> implementing the XMLSignature Standard..
>
> The thing is that i need to validate certificates generated for EJBCA 
> and for external entities ....
>
> My doubt is related to the validation of the certificate generated by 
> the external CA....
>
> I was thinking in using the same PostgreSQL database used by EJBCA and 
> add a table called "trustedCAs" in wich i can almacenate fields like 
> the issuerdn, subjectdn, serial, fingerprint, and the crl distribution 
> point (Wich by the way i think is a good idea for validating the 
> certificates issued by the external ca.... this field could be 
> maintained by a web page with the only function to relate a CA with 
> the location of the CRL ...).
>
> As you see the point of the idea exposed above is to validate a 
> certificate for an enterprise called "my_enterprise" issued by 
> verisign ..... this functionality could be exposed via a webservice 
> interface....
>
> What do you think of the idea .... is the another way of implementing 
> that using EJBCA?? like adding the CAs as external ca or whatever????
>
> I'm newby in the PKI world... :)
>
>
> Francisco
>
>
>
>
>
> ------------------------------------------------------------------------
> Express yourself instantly with MSN Messenger! MSN Messenger 
> <http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejbca-develop@...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

Hello Johan ... i will explain the all thing, could be useful for someone newby like me .. 
 
My idea is to develop a BIG WS that validate signatures made with PKCS12 certificates (.p12). The certificates could be issued by EJBCA or by external CAs like Verisign" 
 
This big WS will receive an XML document with a lot of detached signatures inside it. Something like ....
 
<DOC>
          <TAG_TO_SIGN ID_TRX="1984">
            blah blah
          </TAG_TO_SIGN>
          <SIGNATURE ID="1"> blah </SIGNATURE>
          <SIGNATURE ID="2"> blah </SIGNATURE>
          <SIGNATURE ID="3"> blah </SIGNATURE>
</DOC>
 
(There is a business logic in the signature process with respect to the representation of dependence relation between the signatures but i'm sure that it is not necesary to drill down so far...)
 
So, The point is that i will have to validate the signatures 
 
Ok, Suposse i'm going to validate signature "1". 
 
The WS Will first search for the KeyInfo Element inside the signature element .... and will see wich was the CA that issued the certificate with wich the signature was made So far there is nothing related to EJBCA........So... Once i know wich was the CA that issue the certificate ... i will DECIDE if it was a "LOCAL CA inside EJBCA" ..      or an external CA like verisign...
 
1) If it was and internal CA .. i will consult the status of the certificate using some method of EJBCA (WS, OCSP, CRL or wathever...) 
 
2) If the certificate was issued by an external CA, like verisign ... starts the problem.......... I though that could be a good idea "to reuse the same database used by ejbca....just for the sake to don't create another one... so simple as that..." ... i'm not planing doing an addon to EJBCA ... just to use the same database ...... so i'm thinking in create a new table in wich i can store certain data to use to search for a given CA and the most important thing each record of the table will have a field with the location of the CRL so i could... use OTHER STANDALONE WS wich i can CALL and pass the "URL" an the "serial number of the certificate" and it could a return me a code 
 
SO, what do you thing of the idea of use a TABLE to mantain the list of TRUSTED CA and the locations of it CRL List(and intermediates CAs maybe in the same table..) in a way to know if i "trust or not in a given CA"... 
 
Maybe my question it's to easy ... and my explanation was to long hahah ... hope you forgive me =)
 
I'm currently discarting the idea of consulting the status of "external certificate" by OCSP services provided by external CAs... because it will involve to implement "different web services clients of connector in general" to "each OCSP service" because everyone could use different input and output parameters.... and using a CRL location will be more easy because i can simple use a general java class that resolve the problem using the URLConecction class
 
Thanks for your time
 
Francisco> Date: Thu, 27 Dec 2007 18:53:21 +0100> From: ejbca-support@...> To: ejbca-develop@...> Subject: Re: [Ejbca-develop] validate external certificates> > Hi Francicso,> > I'm not 100% sure I understood your idea, but I'm imagining the > following use-case:> > 1. Someone sends a certificate to an EJBCA installation through WS> 2. If internal issuer → validate directly by EJBCA> If external issuer and issuer is in a list of approved issuers → let > EJBCA fetch CRL and validate cert> 3. Return result> > This would be a great service, but wouldn't it be better suited as a > separate/addon application (that may or may not be deployed in the same > app-server)? That way it could be made more general and configurable to > not allow incoming traffic to the CA by pushing EJBCA CRLs to the > verification service..> > 1. Recieve WS> 2. Check if issuer is approved by consulting local database> 3. Check (cached/pushed) CRL in database or OCSP depending on content of > certificate> 4. Return response> > And maybe it would be nice to have the entire CA-certificates base-64 > encoded in the database and the subjectDN to search for..> > Just some ideas,> Johan> > Francisco Sepulveda skrev:> > Hello guys> >> > I'm designing a PKI module wich i want to build using EJBCA for > > generating the certificates and the Apache-XML-Security API for > > implementing the XMLSignature Standard..> >> > The thing is that i need to validate certificates generated for EJBCA > > and for external entities ....> >> > My doubt is related to the validation of the certificate generated by > > the external CA....> >> > I was thinking in using the same PostgreSQL database used by EJBCA and > > add a table called "trustedCAs" in wich i can almacenate fields like > > the issuerdn, subjectdn, serial, fingerprint, and the crl distribution > > point (Wich by the way i think is a good idea for validating the > > certificates issued by the external ca.... this field could be > > maintained by a web page with the only function to relate a CA with > > the location of the CRL ...).> >> > As you see the point of the idea exposed above is to validate a > > certificate for an enterprise called "my_enterprise" issued by > > verisign ..... this functionality could be exposed via a webservice > > interface....> >> > What do you think of the idea .... is the another way of implementing > > that using EJBCA?? like adding the CAs as external ca or whatever????> >> > I'm newby in the PKI world... :)> >> >> > Francisco> >> >> >> >> >> > ------------------------------------------------------------------------> > Express yourself instantly with MSN Messenger! MSN Messenger > > <http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/>> > ------------------------------------------------------------------------> >> > -------------------------------------------------------------------------> > This SF.net email is sponsored by: Microsoft> > Defy all challenges. Microsoft(R) Visual Studio 2005.> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> > ------------------------------------------------------------------------> >> > _______________________________________________> > Ejbca-develop mailing list> > Ejbca-develop@...> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop> > > > > -------------------------------------------------------------------------> This SF.net email is sponsored by: Microsoft> Defy all challenges. Microsoft(R) Visual Studio 2005.> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> _______________________________________________> Ejbca-develop mailing list> Ejbca-develop@...> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Well.. I was a bit out of line there.. =)

There is nothing wrong with using the same database. The only problems I 
could think of are:
- The username/password might be stored in a less secured place than the 
CA's config files?
- Future conflicts if someone creates a new table with the same name as 
in the official tree.

About the trust:
Does the <SIGNATURE..../> contain the signer's certificate?
Then I would do:
1. Verify signature of payload with signer's certificate
2. Verify signature of signer's certificate with CA-certificate
3. Fetch CRL from location specified in signer's certificate (if no 
valid cached is available)
4. Verify that CRL is signed with CA-certificate
5. Lookup signer's certificate in valid CRL or fail otherwise
and store both CA-certificates and fetched CRLs in different tables.

If you allow signer certificates from sub-CAs you must also verify the 
chain until you get to the trusted root for the sub-CA.

/J

Francisco Sepulveda skrev:
> Hello Johan ... i will explain the all thing, could be useful for 
> someone newby like me ..
>
> My idea is to develop a BIG WS that validate signatures made with 
> PKCS12 certificates (.p12). The certificates could be issued by EJBCA 
> or by external CAs like Verisign"
>
> This big WS will receive an XML document with a lot of detached 
> signatures inside it. Something like ....
>
> <DOC>
> <TAG_TO_SIGN ID_TRX="1984">
> blah blah
> </TAG_TO_SIGN>
> <SIGNATURE ID="1"> blah </SIGNATURE>
> <SIGNATURE ID="2"> blah </SIGNATURE>
> <SIGNATURE ID="3"> blah </SIGNATURE>
> </DOC>
>
> (There is a business logic in the signature process with respect to 
> the representation of dependence relation between the signatures but 
> i'm sure that it is not necesary to drill down so far...)
>
> So, The point is that i will have to validate the signatures
>
> Ok, Suposse i'm going to validate signature "1".
>
> The WS Will first search for the KeyInfo Element inside the signature 
> element .... and will see wich was the CA that issued the certificate 
> with wich the signature was made So far there is nothing related to 
> EJBCA........So... Once i know wich was the CA that issue the 
> certificate ... i will DECIDE if it was a "LOCAL CA inside EJBCA" .. 
> or an external CA like verisign...
>
> 1) If it was and internal CA .. i will consult the status of the 
> certificate using some method of EJBCA (WS, OCSP, CRL or wathever...)
>
> 2) If the certificate was issued by an external CA, like verisign ... 
> starts the problem.......... I though that could be a good idea "to 
> reuse the same database used by ejbca....just for the sake to don't 
> create another one... so simple as that..." ... i'm not planing doing 
> an addon to EJBCA ... just to use the same database ...... so i'm 
> thinking in create a new table in wich i can store certain data to use 
> to search for a given CA and the most important thing each record of 
> the table will have a field with the location of the CRL so i could... 
> use OTHER STANDALONE WS wich i can CALL and pass the "URL" an the 
> "serial number of the certificate" and it could a return me a code
>
> SO, what do you thing of the idea of use a TABLE to mantain the list 
> of TRUSTED CA and the locations of it CRL List(and intermediates CAs 
> maybe in the same table..) in a way to know if i "trust or not in a 
> given CA"...
>
> Maybe my question it's to easy ... and my explanation was to long 
> hahah ... hope you forgive me =)
>
> I'm currently discarting the idea of consulting the status of 
> "external certificate" by OCSP services provided by external CAs... 
> because it will involve to implement "different web services clients 
> of connector in general" to "each OCSP service" because everyone could 
> use different input and output parameters.... and using a CRL location 
> will be more easy because i can simple use a general java class that 
> resolve the problem using the URLConecction class
>
> Thanks for your time
>
> Francisco
>
>
>
> > Date: Thu, 27 Dec 2007 18:53:21 +0100
> > From: ejbca-support@...
> > To: ejbca-develop@...
> > Subject: Re: [Ejbca-develop] validate external certificates
> >
> > Hi Francicso,
> >
> > I'm not 100% sure I understood your idea, but I'm imagining the
> > following use-case:
> >
> > 1. Someone sends a certificate to an EJBCA installation through WS
> > 2. If internal issuer → validate directly by EJBCA
> > If external issuer and issuer is in a list of approved issuers → let
> > EJBCA fetch CRL and validate cert
> > 3. Return result
> >
> > This would be a great service, but wouldn't it be better suited as a
> > separate/addon application (that may or may not be deployed in the same
> > app-server)? That way it could be made more general and configurable to
> > not allow incoming traffic to the CA by pushing EJBCA CRLs to the
> > verification service..
> >
> > 1. Recieve WS
> > 2. Check if issuer is approved by consulting local database
> > 3. Check (cached/pushed) CRL in database or OCSP depending on 
> content of
> > certificate
> > 4. Return response
> >
> > And maybe it would be nice to have the entire CA-certificates base-64
> > encoded in the database and the subjectDN to search for..
> >
> > Just some ideas,
> > Johan
> >
> > Francisco Sepulveda skrev:
> > > Hello guys
> > >
> > > I'm designing a PKI module wich i want to build using EJBCA for
> > > generating the certificates and the Apache-XML-Security API for
> > > implementing the XMLSignature Standard..
> > >
> > > The thing is that i need to validate certificates generated for EJBCA
> > > and for external entities ....
> > >
> > > My doubt is related to the validation of the certificate gener 
> ated by
> > > the external CA....
> > >
> > > I was thinking in using the same PostgreSQL database used by EJBCA 
> and
> > > add a table called "trustedCAs" in wich i can almacenate fields like
> > > the issuerdn, subjectdn, serial, fingerprint, and the crl 
> distribution
> > > point (Wich by the way i think is a good idea for validating the
> > > certificates issued by the external ca.... this field could be
> > > maintained by a web page with the only function to relate a CA with
> > > the location of the CRL ...).
> > >
> > > As you see the point of the idea exposed above is to validate a
> > > certificate for an enterprise called "my_enterprise" issued by
> > > verisign ..... this functionality could be exposed via a webservice
> > > interface....
> > >
> > > What do you think of the idea .... is the another way of implementing
> > > that using EJ BCA?? like adding the CAs as external ca or whatever????
> > >
> > > I'm newby in the PKI world... :)
> > >
> > >
> > > Francisco
> > >
> > >
> > >
> > >
> > >
> > > 
> ------------------------------------------------------------------------
> > > Express yourself instantly with MSN Messenger! MSN Messenger
> > > <http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/>
> > > 
> ------------------------------------------------------------------------
> > >
> > > 
> -------------------------------------------------------------------------
> > > This SF.net email is sponsored by: Microsoft
> > > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > 
> ------------------------------------------------------------------------
> > >
> > > _______________________________ ________________
> > > Ejbca-develop mailing list
> > > Ejbca-develop@...
> > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> > >
> >
> >
> > 
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Ejbca-develop mailing list
> > Ejbca-develop@...
> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
> ------------------------------------------------------------------------
> Express yourself instantly with MSN Messenger! MSN Messenger 
> <http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejbca-develop@...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

Yes ... the <SIGNATURE> will contain the signer certificate and indeed it will contain the whole chain of certificates till the root certificate so i could analyze the certificate and search for fields like the serial number and so on... 
 
I decided to include the whole chain certificate, because if i just include the end-entity certificate i could get problems deciding the rigth CA that issued the certificate because i can create a CA in EJBCA using the same DN as verisign ... that way the application could not decide if it is the local verisign or the REAL verisign ....
 
With you comment of store the CA's Cetificates and CRLs in different tables i get a doubt ...maybe not related directly with your comment  
 
So far i was just thinking in a service that validate a document with a given signature totally "on the fly" or ... "mantaining in memory all the CRLs, etc.." 
 
Do you think is a good idea to mantain a table with the CRLs and a timestamp of the day i got it and maybe i kind of log table of the validated signatures with the certificates used.. in a way to resolve conflict in the future .. or it is not neccesary .. 
 
PS: I will create a table with a spanish name so i could avoid collisions with the official tree of EJBCA table hahahah =P
 
PS: I will analyze the key recovery features provided by EJBCA in a couple of days ... but as an introductory question please confirm my theory .... "The big deal about Key Recovery is that i can regenerate a p12 file with the SAME data in case a lost my certificate ".........or i get it wrong
 
 
 
Francis
 
> Date: Thu, 27 Dec 2007 21:42:47 +0100> From: ejbca-support@...> To: ejbca-develop@...> Subject: Re: [Ejbca-develop] validate external certificates> > Well.. I was a bit out of line there.. =)> > There is nothing wrong with using the same database. The only problems I > could think of are:> - The username/password might be stored in a less secured place than the > CA's config files?> - Future conflicts if someone creates a new table with the same name as > in the official tree.> > About the trust:> Does the <SIGNATURE..../> contain the signer's certificate?> Then I would do:> 1. Verify signature of payload with signer's certificate> 2. Verify signature of signer's certificate with CA-certificate> 3. Fetch CRL from location specified in signer's certificate (if no > valid cached is available)> 4. Verify that CRL is signed with CA-certificate> 5. Lookup signer's certificate in valid CRL or fail otherwise> and store both CA-certificates and fetched CRLs in different tables.> > If you allow signer certificates from sub-CAs you must also verify the > chain until you get to the trusted root for the sub-CA.> > /J> > Francisco Sepulveda skrev:> > Hello Johan ... i will explain the all thing, could be useful for > > someone newby like me ..> >> > My idea is to develop a BIG WS that validate signatures made with > > PKCS12 certificates (.p12). The certificates could be issued by EJBCA > > or by external CAs like Verisign"> >> > This big WS will receive an XML document with a lot of detached > > signatures inside it. Something like ....> >> > <DOC>> > <TAG_TO_SIGN ID_TRX="1984">> > blah blah> > </TAG_TO_SIGN>> > <SIGNATURE ID="1"> blah </SIGNATURE>> > <SIGNATURE ID="2"> blah </SIGNATURE>> > <SIGNATURE ID="3"> blah </SIGNATURE>> > </DOC>> >> > (There is a business logic in the signature process with respect to > > the representation of dependence relation between the signatures but > > i'm sure that it is not necesary to drill down so far...)> >> > So, The point is that i will have to validate the signatures> >> > Ok, Suposse i'm going to validate signature "1".> >> > The WS Will first search for the KeyInfo Element inside the signature > > element .... and will see wich was the CA that issued the certificate > > with wich the signature was made So far there is nothing related to > > EJBCA........So... Once i know wich was the CA that issue the > > certificate ... i will DECIDE if it was a "LOCAL CA inside EJBCA" .. > > or an external CA like verisign...> >> > 1) If it was and internal CA .. i will consult the status of the > > certificate using some method of EJBCA (WS, OCSP, CRL or wathever...)> >> > 2) If the certificate was issued by an external CA, like verisign ... > > starts the problem.......... I though that could be a good idea "to > > reuse the same database used by ejbca....just for the sake to don't > > create another one... so simple as that..." ... i'm not planing doing > > an addon to EJBCA ... just to use the same database ...... so i'm > > thinking in create a new table in wich i can store certain data to use > > to search for a given CA and the most important thing each record of > > the table will have a field with the location of the CRL so i could... > > use OTHER STANDALONE WS wich i can CALL and pass the "URL" an the > > "serial number of the certificate" and it could a return me a code> >> > SO, what do you thing of the idea of use a TABLE to mantain the list > > of TRUSTED CA and the locations of it CRL List(and intermediates CAs > > maybe in the same table..) in a way to know if i "trust or not in a > > given CA"...> >> > Maybe my question it's to easy ... and my explanation was to long > > hahah ... hope you forgive me =)> >> > I'm currently discarting the idea of consulting the status of > > "external certificate" by OCSP services provided by external CAs... > > because it will involve to implement "different web services clients > > of connector in general" to "each OCSP service" because everyone could > > use different input and output parameters.... and using a CRL location > > will be more easy because i can simple use a general java class that > > resolve the problem using the URLConecction class> >> > Thanks for your time> >> > Francisco> >> >> >> > > Date: Thu, 27 Dec 2007 18:53:21 +0100> > > From: ejbca-support@...> > > To: ejbca-develop@...> > > Subject: Re: [Ejbca-develop] validate external certificates> > >> > > Hi Francicso,> > >> > > I'm not 100% sure I understood your idea, but I'm imagining the> > > following use-case:> > >> > > 1. Someone sends a certificate to an EJBCA installation through WS> > > 2. If internal issuer → validate directly by EJBCA> > > If external issuer and issuer is in a list of approved issuers → let> > > EJBCA fetch CRL and validate cert> > > 3. Return result> > >> > > This would be a great service, but wouldn't it be better suited as a> > > separate/addon application (that may or may not be deployed in the same> > > app-server)? That way it could be made more general and configurable to> > > not allow incoming traffic to the CA by pushing EJBCA CRLs to the> > > verification service..> > >> > > 1. Recieve WS> > > 2. Check if issuer is approved by consulting local database> > > 3. Check (cached/pushed) CRL in database or OCSP depending on > > content of> > > certificate> > > 4. Return response> > >> > > And maybe it would be nice to have the entire CA-certificates base-64> > > encoded in the database and the subjectDN to search for..> > >> > > Just some ideas,> > > Johan> > >> > > Francisco Sepulveda skrev:> > > > Hello guys> > > >> > > > I'm designing a PKI module wich i want to build using EJBCA for> > > > generating the certificates and the Apache-XML-Security API for> > > > implementing the XMLSignature Standard..> > > >> > > > The thing is that i need to validate certificates generated for EJBCA> > > > and for external entities ....> > > >> > > > My doubt is related to the validation of the certificate gener > > ated by> > > > the external CA....> > > >> > > > I was thinking in using the same PostgreSQL database used by EJBCA > > and> > > > add a table called "trustedCAs" in wich i can almacenate fields like> > > > the issuerdn, subjectdn, serial, fingerprint, and the crl > > distribution> > > > point (Wich by the way i think is a good idea for validating the> > > > certificates issued by the external ca.... this field could be> > > > maintained by a web page with the only function to relate a CA with> > > > the location of the CRL ...).> > > >> > > > As you see the point of the idea exposed above is to validate a> > > > certificate for an enterprise called "my_enterprise" issued by> > > > verisign ..... this functionality could be exposed via a webservice> > > > interface....> > > >> > > > What do you think of the idea .... is the another way of implementing> > > > that using EJ BCA?? like adding the CAs as external ca or whatever????> > > >> > > > I'm newby in the PKI world... :)> > > >> > > >> > > > Francisco> > > >> > > >> > > >> > > >> > > >> > > > > > ------------------------------------------------------------------------> > > > Express yourself instantly with MSN Messenger! MSN Messenger> > > > <http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/>> > > > > > ------------------------------------------------------------------------> > > >> > > > > > -------------------------------------------------------------------------> > > > This SF.net email is sponsored by: Microsoft> > > > Defy all challenges. Microsoft(R) Visual Studio 2005.> > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> > > > > > ------------------------------------------------------------------------> > > >> > > > _______________________________ ________________> > > > Ejbca-develop mailing list> > > > Ejbca-develop@...> > > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop> > > >> > >> > >> > > > > -------------------------------------------------------------------------> > > This SF.net email is sponsored by: Microsoft> > > Defy all challenges. Microsoft(R) Visual Studio 2005.> > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> > > _______________________________________________> > > Ejbca-develop mailing list> > > Ejbca-develop@...> > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop> >> > ------------------------------------------------------------------------> > Express yourself instantly with MSN Messenger! MSN Messenger > > <http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/>> > ------------------------------------------------------------------------> >> > -------------------------------------------------------------------------> > This SF.net email is sponsored by: Microsoft> > Defy all challenges. Microsoft(R) Visual Studio 2005.> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> > ------------------------------------------------------------------------> >> > _______________________________________________> > Ejbca-develop mailing list> > Ejbca-develop@...> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop> > > > > -------------------------------------------------------------------------> This SF.net email is sponsored by: Microsoft> Defy all challenges. Microsoft(R) Visual Studio 2005.> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> _______________________________________________> Ejbca-develop mailing list> Ejbca-develop@...> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

The CRLs has an embedded "best-before-date" you can use.. So when a CRL 
has expired the app should go and get a new one.. (or pre-fetch with 
service in the background to avoid performace hits..)

You probably need an conserved OCSP-response to prove that the signature 
was valid at the time of signing to remove any doubt about about the 
signatures validity..

I've heard that Spanish i growing fast, so you never know.. =) Let me 
know if you need to borrow some Swedish words..

..and you got the basic idea about key-recovery just right.

/Johan

Francisco Sepulveda skrev:
> Yes ... the <SIGNATURE> will contain the signer certificate and indeed 
> it will contain the whole chain of certificates till the root 
> certificate so i could analyze the certificate and search for fields 
> like the serial number and so on...
>
> I decided to include the whole chain certificate, because if i just 
> include the end-entity certificate i could get problems deciding the 
> rigth CA that issued the certificate because i can create a CA in 
> EJBCA using the same DN as verisign ... that way the application could 
> not decide if it is the local verisign or the REAL verisign ....
>
> With you comment of store the CA's Cetificates and CRLs in different 
> tables i get a doubt ...maybe not related directly with your comment
>
> So far i was just thinking in a service that validate a document with 
> a given signature totally "on the fly" or ... "mantaining in memory 
> all the CRLs, etc.."
>
> Do you think is a good idea to mantain a table with the CRLs and a 
> timestamp of the day i got it and maybe i kind of log table of the 
> validated signatures with the certificates used.. in a way to resolve 
> conflict in the future .. or it is not neccesary ..
>
> PS: I will create a table with a spanish name so i could avoid 
> collisions with the official tree of EJBCA table hahahah =P
>
> PS: I will analyze the key recovery features provided by EJBCA in a 
> couple of days ... but as an introductory question please confirm my 
> theory .... "The big deal about Key Recovery is that i can regenerate 
> a p12 file with the SAME data in case a lost my certificate 
> ".........or i get it wrong
>
>
>
> Francis
>
>
>
> > Date: Thu, 27 Dec 2007 21:42:47 +0100
> > From: ejbca-support@...
> > To: ejbca-develop@...
> > Subject: Re: [Ejbca-develop] validate external certificates
> >
> > Well.. I was a bit out of line there.. =)
> >
> > There is nothing wrong with using the same database. The only 
> problems I
> > could think of are:
> > - The username/password might be stored in a less secured place than 
> the
> > CA's config files?
> > - Future conflicts if someone creates a new table with the same name as
> > in the official tree.
> >
> > About the trust:
> > Does the <SIGNATURE..../> contain the signer's certificate?
> > Then I would do:
> > 1. Verify signature of payload with signer's certificate
> > 2. Verify signature of signer's certificate with CA-certificate
> > 3. Fetch CRL from location specified in signer's certificate (if no
> > valid cached is available)
> > 4. Verify that CRL is signed with CA-certificate
> > 5. Lookup signer's certificate in valid CRL or fail otherwise
> > and store both CA-certificates and fetched CRLs in different tables.
> >
> > If you allow signer certificates from sub-CAs you must also verify the
> > chain until you get to the trusted root for the sub-CA.
> >
> > /J
> >
> > Francisco Sepulveda skrev:
> > > Hello Johan ... i will explain the all thing, could be useful for
> > > someone newby like me ..
> > >
> > > My idea is to develop a BIG WS that validate signatures made with
> > > PKCS12 certificates (.p12). The certificates could be issued by EJBCA
> > > or by external CAs like Verisign"
> > >
> > > This big WS will receive an XML document with a lot of detached
> > > signatures inside it. Something like ....
> > >
> > > <DOC>
> > > <TAG_TO_SIGN ID_TRX="1984"> ;
> > > blah blah
> > > </TAG_TO_SIGN>
> > > <SIGNATURE ID="1"> blah </SIGNATURE>
> > > <SIGNATURE ID="2"> blah </SIGNATURE>
> > > <SIGNATURE ID="3"> blah </SIGNATURE>
> > > </DOC>
> > >
> > > (There is a business logic in the signature process with respect to
> > > the representation of dependence relation between the signatures but
> > > i'm sure that it is not necesary to drill down so far...)
> > >
> > > So, The point is that i will have to validate the signatures
> > >
> > > Ok, Suposse i'm going to validate signature "1".
> > >
> > > The WS Will first search for the KeyInfo Element inside the signature
> > > element .... and will see wich was the CA that issued the certificate
> > > with wich the signature was made So far there is nothing related to
> > > EJBCA........So... Once i know wich was the CA that issue the
> > > certificate ... i will DECIDE if it was a "LOCAL CA inside EJBCA" ..
> > > or an external CA like verisign...
> > >
> > > 1) If it was and internal CA .. i will consult the status of the
> > > certificate using some method of EJBCA (WS, OCSP, CRL or wathever...)
> > >
> > > 2) If the certificate was issued by an external CA, like verisign ...
> > > starts the problem.......... I though that could be a good idea "to
> > > reuse the same database used by ejbca....just for the sake to don't
> > > create another one... so simple as that..." ... i'm not planing doing
> > > an addon to EJBCA ... just to use the same database ...... so i'm
> > > thinking in create a new table in wich i can store certain data to 
> use
> > > to search for a given CA and the most important thing each record of
> > > the table will have a field with the location of the CRL so i 
> could...
> > > use OTHER STANDALONE WS wich i can CALL and pass the "URL" an the
> > > "serial number of the certificate" and it could a return me a code
> > >
> > > SO, what do you thing of the idea of use a TABLE to mantain the list
> > > of TRUSTED CA and the locations of it CRL List(and intermediates CAs
> > > maybe in the same table..) in a way to know if i "trust or not in a
> > > given CA"...
> > >
> > > Maybe my question it's to easy ... and my explanation was to long
> > > hahah ... hope you forgive me =)
> > >
> > > I'm currently discarting the idea of consulting the status of
> > > "external certificate" by OCSP services provided by external CAs...
> > > because it will involve to implement "different web services clients
> > > of connector in general" to "each OCSP service" because everyone 
> could
> > > use different input and output parameters.... and using a CRL 
> location
> > > will be more easy because i can simple use a general java class that
> > > resolve the problem using the URLConecction class
> > >
> > > Thanks for your time
> > >
> > > Francisco
> > >
> > >
> > >
> > > > Date: Thu, 27 Dec 2007 18:53:21 +0100
> > > > From: ejbca-support@...
> > > > To: ejbca-develop@...
> > > > Subject: Re: [Ejbca-develop] validate external certificates
> > > >
> > > > Hi Francicso,
> > > >
> > > > I'm not 100% sure I understood your idea, but I'm imagining the
> > > > following use-case:
> > > >
> > > > 1. Someone sends a certificate to an EJBCA installation through WS
> > > > 2. If internal issuer → validate directly by EJBCA
> > > > If external issuer and issuer is in a list of approved issuers → let
> > > > EJBCA fetch CRL and validate cert
> > > > 3. Return result
> > > >
> > > > This would be a great service, but wouldn't it be better suited as a
> > > > separate/addon application (that may or may not be deployed in 
> the same
> > > > app-server)? That way it could be made more general and 
> configurable to
> > > > not allow incoming traffic to the CA by pushing EJBCA CRLs to the
> > > > verification service..
> > > >
> > > > 1. Recieve WS
> > > > 2. Check if issuer is approved by consulting local database
> > > > 3. Check (cached/pushed) CRL in database or OCSP depending on
> > > content of
> > > > certificate
> > > > 4. Return response
> > > >
> > > > And maybe it would be nice to have the entire CA-certificates 
> base-64
> > > > encoded in the database and the subjec tDN to search for..
> > > >
> > > > Just some ideas,
> > > > Johan
> > > >
> > > > Francisco Sepulveda skrev:
> > > > > Hello guys
> > > > >
> > > > > I'm designing a PKI module wich i want to build using EJBCA for
> > > > > generating the certificates and the Apache-XML-Security API for
> > > > > implementing the XMLSignature Standard..
> > > > >
> > > > > The thing is that i need to validate certificates generated 
> for EJBCA
> > > > > and for external entities ....
> > > > >
> > > > > My doubt is related to the validation of the certificate gener
> > > ated by
> > > > > the external CA....
> > > > >
> > > > > I was thinking in using the same PostgreSQL database used by 
> EJBCA
> > > and
> > > > > add a table called "trustedCAs" in w ich i can almacenate 
> fields like
> > > > > the issuerdn, subjectdn, serial, fingerprint, and the crl
> > > distribution
> > > > > point (Wich by the way i think is a good idea for validating the
> > > > > certificates issued by the external ca.... this field could be
> > > > > maintained by a web page with the only function to relate a CA 
> with
> > > > > the location of the CRL ...).
> > > > >
> > > > > As you see the point of the idea exposed above is to validate a
> > > > > certificate for an enterprise called "my_enterprise" issued by
> > > > > verisign ..... this functionality could be exposed via a 
> webservice
> > > > > interface....
> > > > >
> > > > > What do you think of the idea .... is the another way of 
> implementing
> > > > > that using EJ BCA?? like adding the CAs as external ca or 
> whatever? ???
> > > > >
> > > > > I'm newby in the PKI world... :)
> > > > >
> > > > >
> > > > > Francisco
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > 
> ------------------------------------------------------------------------
> > > > > Express yourself instantly with MSN Messenger! MSN Messenger
> > > > > <http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/>
> > > > >
> > > 
> ------------------------------------------------------------------------
> > > > >
> > > > >
> > > 
> -------------------------------------------------------------------------
> > > > > This SF.net email is sponsored by: Microsoft
> > > > > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > > > > http://clk.atdmt.com/ MRT/go/vse0120000070mrt/direct/01/
> > > > >
> > > 
> ------------------------------------------------------------------------
> > > > >
> > > > > _______________________________ ________________
> > > > > Ejbca-develop mailing list
> > > > > Ejbca-develop@...
> > > > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> > > > >
> > > >
> > > >
> > > >
> > > 
> -------------------------------------------------------------------------
> > > > This SF.net email is sponsored by: Microsoft
> > > > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > > _______________________________________________
> > > > Ejbca-develop mailing list
> > > > Ejbca-develop@...
> > > > h ttps://lists.sourceforge.net/lists/listinfo/ejbca-develop
> > >
> > > 
> ------------------------------------------------------------------------
> > > Express yourself instantly with MSN Messenger! MSN Messenger
> > > <http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/>
> > > 
> ------------------------------------------------------------------------
> > >
> > > 
> -------------------------------------------------------------------------
> > > This SF.net email is sponsored by: Microsoft
> > > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > 
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Ejbca-develop mailing list
> > > Ejbca-develop@...
> > > https://lists.sourceforge.net/lists/list info/ejbca-develop
> > >
> >
> >
> > 
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Ejbca-develop mailing list
> > Ejbca-develop@...
> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
>
> ------------------------------------------------------------------------
> Express yourself instantly with MSN Messenger! MSN Messenger 
> <http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejbca-develop@...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

Hi Pedro,

http://www.ejbca.org/manual.html#Named%20curves has some examples of 
curves supported by the Bouncycastle crypto provider.

Hope this helps,
Johan

Pedro Almeida skrev:
> Hello there,
>
> What's supposed to be introduced in the "ECDSA KeySpec" field at the 
> Edit/Create CA form?
>
> Thanks for your support,
> Pedro
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejbca-develop@...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

So in what form should we fill it, like "prime192v3","prime192v3", and so on
?

On Dec 27, 2007 12:34 PM, Johan Eklund <ejbca-support@...> wrote:

> Hi Pedro,
>
> http://www.ejbca.org/manual.html#Named%20curves has some examples of
> curves supported by the Bouncycastle crypto provider.
>
> Hope this helps,
> Johan
>
> Pedro Almeida skrev:
> > Hello there,
> >
> > What's supposed to be introduced in the "ECDSA KeySpec" field at the
> > Edit/Create CA form?
> >
> > Thanks for your support,
> > Pedro
> > ------------------------------------------------------------------------
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Ejbca-develop mailing list
> > Ejbca-develop@...
> > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ejbca-develop mailing list
> Ejbca-develop@...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

Just enter "prime192v3" or any other curve you choose.. but without the 
"-chars.. =)

Pedro Almeida skrev:
> So in what form should we fill it, like "prime192v3","prime192v3", and 
> so on ?
>
> On Dec 27, 2007 12:34 PM, Johan Eklund < ejbca-support@... 
> <mailto:ejbca-support@...>> wrote:
>
>     Hi Pedro,
>
>     http://www.ejbca.org/manual.html#Named%20curves has some examples of
>     curves supported by the Bouncycastle crypto provider.
>
>     Hope this helps,
>     Johan
>
>     Pedro Almeida skrev:
>     > Hello there,
>     >
>     > What's supposed to be introduced in the "ECDSA KeySpec" field at the
>     > Edit/Create CA form?
>     >
>     > Thanks for your support,
>     > Pedro
>     >
>     ------------------------------------------------------------------------
>
>     >
>     >
>     -------------------------------------------------------------------------
>     > This SF.net email is sponsored by: Microsoft
>     > Defy all challenges. Microsoft(R) Visual Studio 2005.
>     > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > Ejbca-develop mailing list
>     > Ejbca-develop@...
>     <mailto:Ejbca-develop@...>
>     > https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>     <https://lists.sourceforge.net/lists/listinfo/ejbca-develop>
>     >
>
>
>     -------------------------------------------------------------------------
>     This SF.net email is sponsored by: Microsoft
>     Defy all challenges. Microsoft(R) Visual Studio 2005.
>     http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>     _______________________________________________
>     Ejbca-develop mailing list
>     Ejbca-develop@...
>     <mailto:Ejbca-develop@...>
>     https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejbca-develop@...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>

EJBCA uses standard JAX-WS, i.e. SUns reference implementation of 
Webservice. That should be all needed.
Use the cli client jar as reference.

XML/WS is really not so nice with regards to debugging. I almost feel 
sorry for you :-)

Cheers,
Tomas



Ztefan Frizkowitz skrev:
> After I got the ejbcawscli-client to work I created a small application with
> a webpage and an EJB from where I want the communicate with EJBCA to happen.
> 
> But when I run it there is some sort of SAX-parsing error. At the end of the
> stacktrace it says 'XInclude' is not recognized???   
> 
> Do I need som special version of xerces or something else to make this work?
> 
> /Ztefan
> 
> 
> 15:12:14,621 ERROR [EB_CallEJBCA] Failed to create a new SAX
> parser[Ljava.lang.StackTraceElement;@1b4e557org.jboss.xb.binding.JBossXBException:
> Failed to create a new SAX parser
> 15:12:14,621 ERROR [STDERR] org.jboss.xb.binding.JBossXBRuntimeException:
> Failed to create a new SAX parser
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.xb.binding.UnmarshallerFactory$UnmarshallerFactoryImpl.newUnmarshaller(UnmarshallerFactory.java:100)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ws.metadata.config.JBossWSConfigFactory.parse(JBossWSConfigFactory.java:76)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ws.metadata.config.JBossWSConfigFactory.getConfig(JBossWSConfigFactory.java:134)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ws.metadata.umdm.EndpointMetaData.initEndpointConfig(EndpointMetaData.java:683)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.rebuildEndpointMetaData(JAXWSClientMetaDataBuilder.java:272)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getPortInternal(ServiceDelegateImpl.java:274)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getPort(ServiceDelegateImpl.java:200)
> 15:12:14,621 ERROR [STDERR] 	at
> javax.xml.ws.Service.getPort(Service.java:116)
> 15:12:14,621 ERROR [STDERR] 	at
> org.ejbca.core.protocol.ws.client.gen.EjbcaWSService.getEjbcaWSPort(Unknown
> Source)
> 15:12:14,621 ERROR [STDERR] 	at
> se.police.rps.cert.logik.EB_CallEJBCA.init(Unknown Source)
> 15:12:14,621 ERROR [STDERR] 	at
> se.police.rps.cert.fasad.EB_FasadImpl.callEJBCA(Unknown Source)
> 15:12:14,621 ERROR [STDERR] 	at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 15:12:14,621 ERROR [STDERR] 	at
> sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 15:12:14,621 ERROR [STDERR] 	at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 15:12:14,621 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Unknown
> Source)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:57)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:94)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.ejb3.stateful.StatefulInstanceInterceptor.invoke(StatefulInstanceInterceptor.java:83)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:106)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.ejb3.stateful.StatefulContainer.localInvoke(StatefulContainer.java:204)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.ejb3.stateful.StatefulLocalProxy.invoke(StatefulLocalProxy.java:117)
> 15:12:14,631 ERROR [STDERR] 	at $Proxy339.callEJBCA(Unknown Source)
> 15:12:14,631 ERROR [STDERR] 	at EB_CertServlet.doPost(Unknown Source)
> 15:12:14,631 ERROR [STDERR] 	at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> 15:12:14,631 ERROR [STDERR] 	at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 15:12:14,631 ERROR [STDERR] 	at java.lang.Thread.run(Unknown Source)
> 15:12:14,631 ERROR [STDERR] Caused by:
> org.jboss.xb.binding.JBossXBException: Failed to create a new SAX parser
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.xb.binding.parser.sax.SaxJBossXBParser.<init>(SaxJBossXBParser.java:96)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.xb.binding.UnmarshallerImpl.<init>(UnmarshallerImpl.java:55)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.xb.binding.UnmarshallerFactory$UnmarshallerFactoryImpl.newUnmarshaller(UnmarshallerFactory.java:96)
> 15:12:14,631 ERROR [STDERR] 	... 62 more
> 15:12:14,631 ERROR [STDERR] Caused by:
> javax.xml.parsers.ParserConfigurationException: Feature
> 'http://apache.org/xml/features/xinclude' is not recognized.
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.xb.binding.parser.sax.SaxJBossXBParser.<init>(SaxJBossXBParser.java:92)
> 15:12:14,631 ERROR [STDERR] 	... 64 more
> 15:12:14,631 ERROR [EB_CallEJBCA] null[Ljava.lang.StackTraceElement;@13cd05a

Are you deploying you web-app in jboss-4.2.x ? In that case there is 
some conflict between Jboss-ws and Jax-ws. The only way I know to 
resolve it is to remove jbossws from the deploy directory. i.e. just 
remove the entire directory. Another solution would be to upgrade the 
Jboss-ws version i jboss to a later one compliant with JAX-WS.

// Philip

Ztefan Frizkowitz skrev:
> After I got the ejbcawscli-client to work I created a small application with
> a webpage and an EJB from where I want the communicate with EJBCA to happen.
>
> But when I run it there is some sort of SAX-parsing error. At the end of the
> stacktrace it says 'XInclude' is not recognized???   
>
> Do I need som special version of xerces or something else to make this work?
>
> /Ztefan
>
>
> 15:12:14,621 ERROR [EB_CallEJBCA] Failed to create a new SAX
> parser[Ljava.lang.StackTraceElement;@1b4e557org.jboss.xb.binding.JBossXBException:
> Failed to create a new SAX parser
> 15:12:14,621 ERROR [STDERR] org.jboss.xb.binding.JBossXBRuntimeException:
> Failed to create a new SAX parser
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.xb.binding.UnmarshallerFactory$UnmarshallerFactoryImpl.newUnmarshaller(UnmarshallerFactory.java:100)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ws.metadata.config.JBossWSConfigFactory.parse(JBossWSConfigFactory.java:76)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ws.metadata.config.JBossWSConfigFactory.getConfig(JBossWSConfigFactory.java:134)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ws.metadata.umdm.EndpointMetaData.initEndpointConfig(EndpointMetaData.java:683)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.rebuildEndpointMetaData(JAXWSClientMetaDataBuilder.java:272)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getPortInternal(ServiceDelegateImpl.java:274)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getPort(ServiceDelegateImpl.java:200)
> 15:12:14,621 ERROR [STDERR] 	at
> javax.xml.ws.Service.getPort(Service.java:116)
> 15:12:14,621 ERROR [STDERR] 	at
> org.ejbca.core.protocol.ws.client.gen.EjbcaWSService.getEjbcaWSPort(Unknown
> Source)
> 15:12:14,621 ERROR [STDERR] 	at
> se.police.rps.cert.logik.EB_CallEJBCA.init(Unknown Source)
> 15:12:14,621 ERROR [STDERR] 	at
> se.police.rps.cert.fasad.EB_FasadImpl.callEJBCA(Unknown Source)
> 15:12:14,621 ERROR [STDERR] 	at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 15:12:14,621 ERROR [STDERR] 	at
> sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 15:12:14,621 ERROR [STDERR] 	at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 15:12:14,621 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Unknown
> Source)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:57)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,621 ERROR [STDERR] 	at
> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:94)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.ejb3.stateful.StatefulInstanceInterceptor.invoke(StatefulInstanceInterceptor.java:83)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:106)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.ejb3.stateful.StatefulContainer.localInvoke(StatefulContainer.java:204)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.ejb3.stateful.StatefulLocalProxy.invoke(StatefulLocalProxy.java:117)
> 15:12:14,631 ERROR [STDERR] 	at $Proxy339.callEJBCA(Unknown Source)
> 15:12:14,631 ERROR [STDERR] 	at EB_CertServlet.doPost(Unknown Source)
> 15:12:14,631 ERROR [STDERR] 	at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> 15:12:14,631 ERROR [STDERR] 	at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> 15:12:14,631 ERROR [STDERR] 	at java.lang.Thread.run(Unknown Source)
> 15:12:14,631 ERROR [STDERR] Caused by:
> org.jboss.xb.binding.JBossXBException: Failed to create a new SAX parser
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.xb.binding.parser.sax.SaxJBossXBParser.<init>(SaxJBossXBParser.java:96)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.xb.binding.UnmarshallerImpl.<init>(UnmarshallerImpl.java:55)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.xb.binding.UnmarshallerFactory$UnmarshallerFactoryImpl.newUnmarshaller(UnmarshallerFactory.java:96)
> 15:12:14,631 ERROR [STDERR] 	... 62 more
> 15:12:14,631 ERROR [STDERR] Caused by:
> javax.xml.parsers.ParserConfigurationException: Feature
> 'http://apache.org/xml/features/xinclude' is not recognized.
> 15:12:14,631 ERROR [STDERR] 	at
> org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
> 15:12:14,631 ERROR [STDERR] 	at
> org.jboss.xb.binding.parser.sax.SaxJBossXBParser.<init>(SaxJBossXBParser.java:92)
> 15:12:14,631 ERROR [STDERR] 	... 64 more
> 15:12:14,631 ERROR [EB_CallEJBCA] null[Ljava.lang.StackTraceElement;@13cd05a
>

Yes I am running JBoss 4.2.x.  I will try the solution and see what
happens...   




EJBCA Support wrote:
> 
> Are you deploying you web-app in jboss-4.2.x ? In that case there is 
> some conflict between Jboss-ws and Jax-ws. The only way I know to 
> resolve it is to remove jbossws from the deploy directory. i.e. just 
> remove the entire directory. Another solution would be to upgrade the 
> Jboss-ws version i jboss to a later one compliant with JAX-WS.
> 
> // Philip
> 
> Ztefan Frizkowitz skrev:
>> After I got the ejbcawscli-client to work I created a small application
>> with
>> a webpage and an EJB from where I want the communicate with EJBCA to
>> happen.
>>
>> But when I run it there is some sort of SAX-parsing error. At the end of
>> the
>> stacktrace it says 'XInclude' is not recognized???   
>>
>> Do I need som special version of xerces or something else to make this
>> work?
>>
>> /Ztefan
>>
>>
>> 15:12:14,621 ERROR [EB_CallEJBCA] Failed to create a new SAX
>> parser[Ljava.lang.StackTraceElement;@1b4e557org.jboss.xb.binding.JBossXBException:
>> Failed to create a new SAX parser
>> 15:12:14,621 ERROR [STDERR] org.jboss.xb.binding.JBossXBRuntimeException:
>> Failed to create a new SAX parser
>> 15:12:14,621 ERROR [STDERR] 	at
>> org.jboss.xb.binding.UnmarshallerFactory$UnmarshallerFactoryImpl.newUnmarshaller(UnmarshallerFactory.java:100)
>> 15:12:14,621 ERROR [STDERR] 	at
>> org.jboss.ws.metadata.config.JBossWSConfigFactory.parse(JBossWSConfigFactory.java:76)
>> 15:12:14,621 ERROR [STDERR] 	at
>> org.jboss.ws.metadata.config.JBossWSConfigFactory.getConfig(JBossWSConfigFactory.java:134)
>> 15:12:14,621 ERROR [STDERR] 	at
>> org.jboss.ws.metadata.umdm.EndpointMetaData.initEndpointConfig(EndpointMetaData.java:683)
>> 15:12:14,621 ERROR [STDERR] 	at
>> org.jboss.ws.metadata.builder.jaxws.JAXWSClientMetaDataBuilder.rebuildEndpointMetaData(JAXWSClientMetaDataBuilder.java:272)
>> 15:12:14,621 ERROR [STDERR] 	at
>> org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getPortInternal(ServiceDelegateImpl.java:274)
>> 15:12:14,621 ERROR [STDERR] 	at
>> org.jboss.ws.core.jaxws.spi.ServiceDelegateImpl.getPort(ServiceDelegateImpl.java:200)
>> 15:12:14,621 ERROR [STDERR] 	at
>> javax.xml.ws.Service.getPort(Service.java:116)
>> 15:12:14,621 ERROR [STDERR] 	at
>> org.ejbca.core.protocol.ws.client.gen.EjbcaWSService.getEjbcaWSPort(Unknown
>> Source)
>> 15:12:14,621 ERROR [STDERR] 	at
>> se.police.rps.cert.logik.EB_CallEJBCA.init(Unknown Source)
>> 15:12:14,621 ERROR [STDERR] 	at
>> se.police.rps.cert.fasad.EB_FasadImpl.callEJBCA(Unknown Source)
>> 15:12:14,621 ERROR [STDERR] 	at
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 15:12:14,621 ERROR [STDERR] 	at
>> sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>> 15:12:14,621 ERROR [STDERR] 	at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> 15:12:14,621 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Unknown
>> Source)
>> 15:12:14,621 ERROR [STDERR] 	at
>> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
>> 15:12:14,621 ERROR [STDERR] 	at
>> org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
>> 15:12:14,621 ERROR [STDERR] 	at
>> org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
>> 15:12:14,621 ERROR [STDERR] 	at
>> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>> 15:12:14,621 ERROR [STDERR] 	at
>> org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:57)
>> 15:12:14,621 ERROR [STDERR] 	at
>> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>> 15:12:14,621 ERROR [STDERR] 	at
>> org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:94)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.ejb3.stateful.StatefulInstanceInterceptor.invoke(StatefulInstanceInterceptor.java:83)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:106)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.ejb3.stateful.StatefulContainer.localInvoke(StatefulContainer.java:204)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.ejb3.stateful.StatefulLocalProxy.invoke(StatefulLocalProxy.java:117)
>> 15:12:14,631 ERROR [STDERR] 	at $Proxy339.callEJBCA(Unknown Source)
>> 15:12:14,631 ERROR [STDERR] 	at EB_CertServlet.doPost(Unknown Source)
>> 15:12:14,631 ERROR [STDERR] 	at
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>> 15:12:14,631 ERROR [STDERR] 	at
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>> 15:12:14,631 ERROR [STDERR] 	at java.lang.Thread.run(Unknown Source)
>> 15:12:14,631 ERROR [STDERR] Caused by:
>> org.jboss.xb.binding.JBossXBException: Failed to create a new SAX parser
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.xb.binding.parser.sax.SaxJBossXBParser.<init>(SaxJBossXBParser.java:96)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.xb.binding.UnmarshallerImpl.<init>(UnmarshallerImpl.java:55)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.xb.binding.UnmarshallerFactory$UnmarshallerFactoryImpl.newUnmarshaller(UnmarshallerFactory.java:96)
>> 15:12:14,631 ERROR [STDERR] 	... 62 more
>> 15:12:14,631 ERROR [STDERR] Caused by:
>> javax.xml.parsers.ParserConfigurationException: Feature
>> 'http://apache.org/xml/features/xinclude' is not recognized.
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
>> 15:12:14,631 ERROR [STDERR] 	at
>> org.jboss.xb.binding.parser.sax.SaxJBossXBParser.<init>(SaxJBossXBParser.java:92)
>> 15:12:14,631 ERROR [STDERR] 	... 64 more
>> 15:12:14,631 ERROR [EB_CallEJBCA]
>> null[Ljava.lang.StackTraceElement;@13cd05a
>>   
> 
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Ejbca-develop mailing list
> Ejbca-develop@...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 
> 

-- 
View this message in context: http://www.nabble.com/More-problems-with-the-Webservice-interface-tp14397875p14412957.html
Sent from the EjbCA - Dev mailing list archive at Nabble.com.

Unid-Fnr is a mapping between a non-personal number and a 
personal-number. It is used in Norway for personal integrity reasons, 
you don't want the real personal number in the public certificate, but 
you want to let authorized parties be able to look up the real personal 
number from the information in the certificate.

Cheers,
Tomas


thomas.beckmann@... skrev:
> Hi all,
> 
> Just for my curiousity...
> 
> What is the Unid-Fnr and what is it used for?
> 
> Best regards
> 
> Thomas Beckmann
> 
> Atos Origin GmbH, Theodor-Althoff-Str. 47, D-45133 Essen, Postfach 100 123, D-45001 Essen
> Telefon: +49 201 4305 0, Fax: +49 201 4305 689095, http://www.atosorigin.de
> ING Bank AG, Frankfurt/Main: Konto 001 014 0937, BLZ 500 210 00, Swift / BIC INGBDEFF, IBAN DE74 5002 1000 0010 1409 37
> Geschäftsführer: Wilbert Kieboom, Handelsregister Essen HRB 19354, Ust.-ID.-Nr.: DE147861238
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejbca-develop@...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop