Menu
▾
▴
signserver-develop
You can subscribe to this list here.
| 2008 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
| 2010 |
Jan
(1) |
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2012 |
Jan
(1) |
Feb
(8) |
Mar
(10) |
Apr
|
May
(12) |
Jun
(2) |
Jul
(28) |
Aug
(15) |
Sep
(12) |
Oct
(2) |
Nov
|
Dec
(16) |
| 2013 |
Jan
(30) |
Feb
(1) |
Mar
|
Apr
(11) |
May
(2) |
Jun
(11) |
Jul
(15) |
Aug
(4) |
Sep
(1) |
Oct
(10) |
Nov
(1) |
Dec
(2) |
| 2014 |
Jan
(8) |
Feb
(13) |
Mar
(12) |
Apr
(24) |
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
(2) |
Dec
(1) |
| 2015 |
Jan
(3) |
Feb
(6) |
Mar
|
Apr
|
May
(7) |
Jun
(7) |
Jul
(3) |
Aug
(5) |
Sep
(1) |
Oct
(8) |
Nov
(6) |
Dec
|
| 2016 |
Jan
|
Feb
(3) |
Mar
(5) |
Apr
(9) |
May
(26) |
Jun
(8) |
Jul
|
Aug
|
Sep
(11) |
Oct
(8) |
Nov
(1) |
Dec
(2) |
| 2017 |
Jan
(4) |
Feb
(7) |
Mar
(7) |
Apr
(4) |
May
(1) |
Jun
(5) |
Jul
(3) |
Aug
(3) |
Sep
(1) |
Oct
(4) |
Nov
(5) |
Dec
(1) |
| 2018 |
Jan
(4) |
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
| 2020 |
Jan
(3) |
Feb
|
Mar
(2) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2025 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Antoine L. <ant...@yo...> - 2012-08-29 21:43:37
|
Hi everyone, I want to create my own Authorizer class, so I had one class in Signserver-ejb to do this. In the isAuthorized method, I want to call a web service. So I add a web service client with netbeans in signserver-ejb. No problem here, when I clean and build this ejb, it works. The problem comes when I want to run : ant clean deploy for the project. The build fails because it doesn't find the generated sources (generated by jax ws). The cause is that in signserver.xmli, there is a tag javac which starts the compilation of signserver-ejb. The generated sources are not present at this moment so it fails. Why signserver-ejb is build like that and not with its build.xml ? I try to exclude this file in the javac tag, the compilation works but signserver-ejb.jar in dist-server directory does not include this file while it is present in the output jar of the module (modules/signserver-ejb/build/). Do you have any ideas to solve this problem ? Thanks a lot. Have a good afternoon. Best regards, Antoine Louiset |
|
From: ejbca-support <ejb...@pr...> - 2012-08-07 11:57:41
|
On 2012-08-07 08:40, Antoine Louiset wrote: > Hi everyone, > > I develop my own ejb with maven and I want to use > SigningAndValidationAPI. Do you know if it is possible ? Hi Antoine, In theory you can use any build system. However, if you do not use ant you are essentially on your own. > > Is it scheduled to use maven for signserver ? No, AFAIK a switch to is not scheduled for EJBCA pr SignServer. Most people who build applications around our products do it through protocols, our hope is that the "core" has what is needed :-) > > Have a nice day. U2! Anders tech support > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > SignServer-develop mailing list > Sig...@li... > https://lists.sourceforge.net/lists/listinfo/signserver-develop > |
|
From: Antoine L. <ant...@yo...> - 2012-08-07 06:40:26
|
Hi everyone, I develop my own ejb with maven and I want to use SigningAndValidationAPI. Do you know if it is possible ? Is it scheduled to use maven for signserver ? Have a nice day. -- Antoine Louiset Tél : +33 6 76 66 80 34 Responsable du projet Yousign Mail : ant...@yo... |
|
From: Antoine L. <ant...@yo...> - 2012-08-06 13:25:47
|
It's a pleasure Markus ! Antoine Le 06/08/2012 12:58, Markus Kilås a écrit : > Thank you Antoine! > > I have created the ticket https://jira.primekey.se/browse/DSS-517 where > we can continue the discussion on where to best put the guide and if we > can make any improvements. > > > Best regards, > Markus > > On 2012-08-06 12:14, Antoine Louiset wrote: >> Hi everyone, >> >> I write a script which install signserver 3.2.2 on a linux system. I >> test it on debian 6. >> >> I hope it will be useful for many people. This script is the first >> version. It could of course be improved. >> >> Don't hesitate to contact me if you have remarks or if there are bugs. >> >> Have a nice week. >> >> Best regards, >> >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> >> >> >> _______________________________________________ >> SignServer-develop mailing list >> Sig...@li... >> https://lists.sourceforge.net/lists/listinfo/signserver-develop >> > > -- Antoine Louiset Tél : +33 6 76 66 80 34 Responsable du projet Yousign Mail : ant...@yo... |
|
From: Markus K. <ma...@pr...> - 2012-08-06 10:59:07
|
Thank you Antoine! I have created the ticket https://jira.primekey.se/browse/DSS-517 where we can continue the discussion on where to best put the guide and if we can make any improvements. Best regards, Markus On 2012-08-06 12:14, Antoine Louiset wrote: > Hi everyone, > > I write a script which install signserver 3.2.2 on a linux system. I > test it on debian 6. > > I hope it will be useful for many people. This script is the first > version. It could of course be improved. > > Don't hesitate to contact me if you have remarks or if there are bugs. > > Have a nice week. > > Best regards, > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > SignServer-develop mailing list > Sig...@li... > https://lists.sourceforge.net/lists/listinfo/signserver-develop > -- Kind regards, Markus Kilås Security Consultant & Developer PrimeKey Solutions AB Anderstorpsv. 16 171 54 Solna Sweden Phone: +46 70 424 94 85 Skype: markusatskype Email: mar...@pr... www.primekey.se |
|
From: Antoine L. <ant...@yo...> - 2012-08-06 10:25:47
|
Hi everyone, I write a script which install signserver 3.2.2 on a linux system. I test it on debian 6. I hope it will be useful for many people. This script is the first version. It could of course be improved. Don't hesitate to contact me if you have remarks or if there are bugs. Have a nice week. Best regards, -- Antoine Louiset Responsable du projet Yousign Mail : ant...@yo... |
|
From: Antoine L. <ant...@yo...> - 2012-08-02 17:44:06
|
Hi Markus,
See my comments below.
Le 02/08/2012 19:34, Markus Kilås a écrit :
> On 2012-08-02 16:24, Antoine Louiset wrote:
>> Hi Markus,
>>
>> Thanks for your answer.
>>
>> I will of course share the dispatcher when I will develop it (scheduled
>> in october 2012).
> Great!
>
>> In fact, I do not realy understand what is a node...
> In this case I think a node means a server running SignServer. You could
> possibly have multiple servers/nodes behind a load balancer.
>
>> I will integrate in java the SignserverWS functionnalities. Do you
>> advice to use Client-SignServerWS or Client-SigningAndValidationAPI ?
> I would have used Client-SigningAndValidationAPI. That was what I used
> when I created SignServer-Client-CLI. For examples see for instance
> WebServicesDocumentSigner.java.
Very good, thanks.
>
>> The purpose of the process(String workerIdOrName, List<ProcessRequest>
>> requests, List <RequestContext> contexts) method is to set multiple
>> RequestMetadata from multiple contexts. Today, just one context is used
>> for all requests. I think it will be easy to implement in a
>> SignServer-Client project.
> Ok, but wouldn't you then want the first request to use the first
> requestContext and the next request the next one and so on? That would
> not be so easy to understand in the API, maybe then it would be better
> that the process method took only one list which contains pairs of
> ProcessRequest and RequestContext. Something like:
> ---
> List<ProcessResponse> process(String idOrName, List<RequestAndContext>);
>
> class RequestAndContext {
> ProcessRequest processRequest;
> ProcessContext context;
> }
> ---
>
> It would be simple to add a new method with something like that to the
> SignServer-Client-SigningAndValidationAPI project as it would only imply
> changes on the client sides and by keeping the old method it would be
> backward compatible as well.
Exactly ! I will certainly do like that. It's very easy to add methods
in Client-SigningAndValidationAPI, a very good idea to develop this
functionality.
>
> Best regards,
> Markus
>
>>
>> Good afternoon.
>>
>> Best regards,
>>
>> Le 02/08/2012 14:23, Markus Kilås a écrit :
>>> Hi Antoine,
>>>
>>> On 2012-08-02 08:31, Antoine Louiset wrote:
>>>> Hi Markus,
>>>>
>>>> I wonder if signserver could find the worker associated with the mime
>>>> type ? Could the dispatchers do this work ?
>>> There is no Dispatcher doing that currently but it is an excellent
>>> example of what a Dispatcher could be implemented to do. If you
>>> implement a new Dispatcher doing this we would be happy for the
>>> contribution.
>>>
>>>> How does the CallFirstNodeWithStatusOKWSClient work when the fastest
>>>> worker which respond does not correspond to the mime type of the
>>>> document to be signed ?
>>> I am not sure the CallFirstNodeWithStatusOKWSClient even consider that
>>> there might be multiple workers available on each node. I have never
>>> used it.
>>>
>>>> Is is scheduled to add a method process(String workerIdOrName,
>>>> List<ProcessRequest> requests, List <RequestContext> contexts) in the
>>>> SigningAndValidationAPI ?
>>> Is the purpose to be able to supply multiple documents to sign in the
>>> same request?
>>>
>>> There are no concrete plans for it at the moment but what you could do
>>> is to register an issue for a new feature and describe what the
>>> requirements are and how you suggest it could be implemented and we
>>> could keep it into consideration.
>>>
>>>> Could the default validator validate CMS signatures ?
>>> Not currently. There are only certificate validators and a document
>>> validator for XML signatures.
>>>
>>>
>>> Best regards,
>>> Markus
>>>
>>>> Thanks for your reply.
>>>>
>>>> Have a nice day !
>>>>
>>>> Best regards,
>>>>
>>>
>
>
--
Antoine Louiset Tél : +33 6 76 66 80 34
Responsable du projet Yousign Mail : ant...@yo...
|
|
From: Markus K. <ma...@pr...> - 2012-08-02 17:34:12
|
On 2012-08-02 16:24, Antoine Louiset wrote:
> Hi Markus,
>
> Thanks for your answer.
>
> I will of course share the dispatcher when I will develop it (scheduled
> in october 2012).
Great!
>
> In fact, I do not realy understand what is a node...
In this case I think a node means a server running SignServer. You could
possibly have multiple servers/nodes behind a load balancer.
>
> I will integrate in java the SignserverWS functionnalities. Do you
> advice to use Client-SignServerWS or Client-SigningAndValidationAPI ?
I would have used Client-SigningAndValidationAPI. That was what I used
when I created SignServer-Client-CLI. For examples see for instance
WebServicesDocumentSigner.java.
>
> The purpose of the process(String workerIdOrName, List<ProcessRequest>
> requests, List <RequestContext> contexts) method is to set multiple
> RequestMetadata from multiple contexts. Today, just one context is used
> for all requests. I think it will be easy to implement in a
> SignServer-Client project.
Ok, but wouldn't you then want the first request to use the first
requestContext and the next request the next one and so on? That would
not be so easy to understand in the API, maybe then it would be better
that the process method took only one list which contains pairs of
ProcessRequest and RequestContext. Something like:
---
List<ProcessResponse> process(String idOrName, List<RequestAndContext>);
class RequestAndContext {
ProcessRequest processRequest;
ProcessContext context;
}
---
It would be simple to add a new method with something like that to the
SignServer-Client-SigningAndValidationAPI project as it would only imply
changes on the client sides and by keeping the old method it would be
backward compatible as well.
Best regards,
Markus
>
>
> Good afternoon.
>
> Best regards,
>
> Le 02/08/2012 14:23, Markus Kilås a écrit :
>> Hi Antoine,
>>
>> On 2012-08-02 08:31, Antoine Louiset wrote:
>>> Hi Markus,
>>>
>>> I wonder if signserver could find the worker associated with the mime
>>> type ? Could the dispatchers do this work ?
>> There is no Dispatcher doing that currently but it is an excellent
>> example of what a Dispatcher could be implemented to do. If you
>> implement a new Dispatcher doing this we would be happy for the
>> contribution.
>>
>>> How does the CallFirstNodeWithStatusOKWSClient work when the fastest
>>> worker which respond does not correspond to the mime type of the
>>> document to be signed ?
>> I am not sure the CallFirstNodeWithStatusOKWSClient even consider that
>> there might be multiple workers available on each node. I have never
>> used it.
>>
>>> Is is scheduled to add a method process(String workerIdOrName,
>>> List<ProcessRequest> requests, List <RequestContext> contexts) in the
>>> SigningAndValidationAPI ?
>> Is the purpose to be able to supply multiple documents to sign in the
>> same request?
>>
>> There are no concrete plans for it at the moment but what you could do
>> is to register an issue for a new feature and describe what the
>> requirements are and how you suggest it could be implemented and we
>> could keep it into consideration.
>>
>>> Could the default validator validate CMS signatures ?
>> Not currently. There are only certificate validators and a document
>> validator for XML signatures.
>>
>>
>> Best regards,
>> Markus
>>
>>> Thanks for your reply.
>>>
>>> Have a nice day !
>>>
>>> Best regards,
>>>
>>
>>
>
--
Kind regards,
Markus Kilås
Security Consultant & Developer
PrimeKey Solutions AB
Anderstorpsv. 16
171 54 Solna
Sweden
Phone: +46 70 424 94 85
Skype: markusatskype
Email: mar...@pr...
www.primekey.se
|
|
From: Antoine L. <ant...@yo...> - 2012-08-02 14:25:03
|
Hi Markus, Thanks for your answer. I will of course share the dispatcher when I will develop it (scheduled in october 2012). In fact, I do not realy understand what is a node... I will integrate in java the SignserverWS functionnalities. Do you advice to use Client-SignServerWS or Client-SigningAndValidationAPI ? The purpose of the process(String workerIdOrName, List<ProcessRequest> requests, List <RequestContext> contexts) method is to set multiple RequestMetadata from multiple contexts. Today, just one context is used for all requests. I think it will be easy to implement in a SignServer-Client project. Good afternoon. Best regards, Le 02/08/2012 14:23, Markus Kilås a écrit : > Hi Antoine, > > On 2012-08-02 08:31, Antoine Louiset wrote: >> Hi Markus, >> >> I wonder if signserver could find the worker associated with the mime >> type ? Could the dispatchers do this work ? > There is no Dispatcher doing that currently but it is an excellent > example of what a Dispatcher could be implemented to do. If you > implement a new Dispatcher doing this we would be happy for the > contribution. > >> How does the CallFirstNodeWithStatusOKWSClient work when the fastest >> worker which respond does not correspond to the mime type of the >> document to be signed ? > I am not sure the CallFirstNodeWithStatusOKWSClient even consider that > there might be multiple workers available on each node. I have never > used it. > >> Is is scheduled to add a method process(String workerIdOrName, >> List<ProcessRequest> requests, List <RequestContext> contexts) in the >> SigningAndValidationAPI ? > Is the purpose to be able to supply multiple documents to sign in the > same request? > > There are no concrete plans for it at the moment but what you could do > is to register an issue for a new feature and describe what the > requirements are and how you suggest it could be implemented and we > could keep it into consideration. > >> Could the default validator validate CMS signatures ? > Not currently. There are only certificate validators and a document > validator for XML signatures. > > > Best regards, > Markus > >> Thanks for your reply. >> >> Have a nice day ! >> >> Best regards, >> > > -- Antoine Louiset Tél : +33 6 76 66 80 34 Responsable du projet Yousign Mail : ant...@yo... |
|
From: Markus K. <ma...@pr...> - 2012-08-02 12:23:49
|
Hi Antoine, On 2012-08-02 08:31, Antoine Louiset wrote: > Hi Markus, > > I wonder if signserver could find the worker associated with the mime > type ? Could the dispatchers do this work ? There is no Dispatcher doing that currently but it is an excellent example of what a Dispatcher could be implemented to do. If you implement a new Dispatcher doing this we would be happy for the contribution. > > How does the CallFirstNodeWithStatusOKWSClient work when the fastest > worker which respond does not correspond to the mime type of the > document to be signed ? I am not sure the CallFirstNodeWithStatusOKWSClient even consider that there might be multiple workers available on each node. I have never used it. > > Is is scheduled to add a method process(String workerIdOrName, > List<ProcessRequest> requests, List <RequestContext> contexts) in the > SigningAndValidationAPI ? Is the purpose to be able to supply multiple documents to sign in the same request? There are no concrete plans for it at the moment but what you could do is to register an issue for a new feature and describe what the requirements are and how you suggest it could be implemented and we could keep it into consideration. > > Could the default validator validate CMS signatures ? Not currently. There are only certificate validators and a document validator for XML signatures. Best regards, Markus > > Thanks for your reply. > > Have a nice day ! > > Best regards, > -- Kind regards, Markus Kilås Security Consultant & Developer PrimeKey Solutions AB Anderstorpsv. 16 171 54 Solna Sweden Phone: +46 70 424 94 85 Skype: markusatskype Email: mar...@pr... www.primekey.se |
|
From: Antoine L. <ant...@yo...> - 2012-08-02 06:31:59
|
Hi Markus, I wonder if signserver could find the worker associated with the mime type ? Could the dispatchers do this work ? How does the CallFirstNodeWithStatusOKWSClient work when the fastest worker which respond does not correspond to the mime type of the document to be signed ? Is is scheduled to add a method process(String workerIdOrName, List<ProcessRequest> requests, List <RequestContext> contexts) in the SigningAndValidationAPI ? Could the default validator validate CMS signatures ? Thanks for your reply. Have a nice day ! Best regards, -- Antoine Louiset Tél : +33 6 76 66 80 34 Responsable du projet Yousign Mail : ant...@yo... |
|
From: Markus K. <ma...@pr...> - 2012-08-01 06:40:40
|
I would guess so as if the Dispatcher was configured with signers without valid certificates you would get this error. If you want to be sure you can check what workers the Dispatcher in the test was configured to use. BR, Markus -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Antoine Louiset <ant...@yo...> wrote: Hi Markus, Thanks for your answer. It's ok for me, do you think it will resolve the last error : no active worker available ? Best regards, Antoine Le 31/07/2012 20:37, Markus Kilås a écrit : Hi Antoine, I finally found it. It was there in the change log for the next release all the time, not sure how I could miss it. Anyway, the certificate was renewed as part of https://jira.primekey.se/browse/DSS-483 and the issue was already resolved in the 3.2 branch and will be available in the next release (SignServer 3.2.3). Best regards, Markus On 2012-07-31 10:11, Antoine Louiset wrote: Yes, I use the version 3.2.2. Le 31/07/2012 10:04, Markus Kilås a écrit : I did the same thing but I have much later dates for the TestLimitKeyUsageSigner (5802). Are you really using the latest release (ie. 3.2.2) otherwise upgrading should solve the problem. Best regards, Markus On 2012-07-30 20:56, Antoine Louiset wrote: You were right Markus (as always ! ) ! I have got 2 errors and one fail. I join a screenshot of the admin gui (in the reports.rar file). After launching the tests, we can see that the worker 5802 and others are unavailable. After removing this worker, I launch bin/signserver.sh setproperties modules/SignServer-Module-XMLSigner/src/conf/junittest-part-config.properties to activate its and then the reload command. We can see in the Capture-1.png the result. The signer certificate is indeed valid until 20/04/12. After resolving this problem, there will be one last error !! Have a nice evening. Best regards, Le 30/07/2012 19:05, Markus Kilås a écrit : I am not able to reproduce the test failure you are getting. I also checked the certificate for worker 5802 and it should not expire until year 2021 so it is a very strange error message. Have you tried clearing th database before running the tests in case some signers are left from previous test runs? Best regards, Markus On 2012-07-30 16:54, Antoine Louiset wrote: Ok Markus, no problem ! Thanks ! Best regards, Antoine Le 30/07/2012 16:53, Markus Kilås a écrit : On 2012-07-30 15:08, Antoine Louiset wrote: Hi Markus, Thanks for your fast answer ! I have just one remark for the JCE installation. I don't find it in the installation guide (I read it quickly). I was really surprised it wasn't there. I have registered https://jira.primekey.se/browse/DSS-514. I download JCE policy and it resolves one fail. The problem of the signer 5802 will resolve one fail and one error. So there will be no more fails but I have no idea about the other errors. What do you think about them ? I will try to get back about them. I haven't yet had to time to test it on my machine. Best regards, Markus Good afternoon ! Antoine Le 30/07/2012 10:47, Markus Kilås a écrit : Hi Antoine, See answers below. On 2012-07-28 23:24, Antoine Louiset wrote: Hi Markus, The p12 directory seems to be used to set truststore certificates for JBoss (see http://signserver.org/manual/complete.en.html#4.%20Configure%20web%20server%20keystores) but I think this truststore is just used in the tests of signserver and could be used for the java trust keystore. Jboss and glassfish have their own truststore and keystore, why don't you use them ? That is correct. The truststore in the p12 folder is used both by JBoss and the tests. So if you are going to run the tests you can put a truststore in the p12 folder. I believe the reason for handling it this way is that different application servers have different locations for the truststore and the tests would not know where to find it. In fact where JBoss finds it depends on what is written in the server.xml, so it could also be different if SignServer isn't used for deploying it. The solution we use, to not depend on different application servers and configurations is to decide that it should be placed in the p12 folder of SignServer. In the signserver_build.properties file, there are several properties which are written for the use of JBoss but we do not know if they are needed for Glassfish : httpsserver.bindaddress.* | database.url | deploy.hostname.node* Some are explained in the installation guide, such as "database.url" which is said to be used by JBoss and some comments talks about JBoss in the sample configuration file. But the documentation is lacking for many of the other properties in this aspect. What is the aim of deploy.ssh.* properties ? I think the idea is to be able to deploy to a remote server by transferring the files (signserver.ear etc) over SSH. Not sure if it is working though as I can not find any documentation about it. You are very welcome to test it out if you want and let us know if it is working. If not we might consider either fixing it and adding documentation for it or remove it. Why j2ee.web-nohttps has to be set to true to launch the tests while https is used in these tests ? j2ee.web-nohttps is controlling wither the keystores and truststores should be deployed (to JBoss) or not. The tests should not depend on this setting so if it says somewhere that it must be set to true I would suspect that to be a bug in the documentation. Please report a bug with where you seen it in that case. The most important thing for me today is tests ! I run them, I resolve the problem about trustanchors. I join the results, I do not understand the errors and the fails, have you ever seen them ? From the test report you attached I can see two different failures which probably is also the cause of all the errors. 1. ExtendedHardCodedCryptoTokenTest testStrongCryptoAvailable JCE crypto policy was not installed as the key length was limited expected:<2147483647> but was:<64> This means that you are running the Oracle JDK and have not installed JCE crypto policy. See the installation guide. 2. LimitKeyUsagesTest test01Limit Error Signer 5802 expired at Fri Apr 20 16:18:57 CEST 2012 Looks like the demo signer certificate used has expired. I will run the tests on your continues integration server and see if we have the same problem there. They might just have to be renewed. How can I send my script to install signserver ? If it is less then 40 KB you can just send it to the mailing list, otherwise try to upload it somewhere and send the link or send it directly to me. I take this mail to congratulate you and your team for this project which is really good. Thanks to you for reporting the issues you find. Best regards, Markus Have a nice weekend. Best regards, ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ SignServer-develop mailing list Sig...@li... https://lists.sourceforge.net/lists/listinfo/signserver-develop -- PrimeKey Solutions offers a commercial EJBCA support subscription and training for EJBCA. Please see www.primekey.se or contact in...@pr... for more information. http://www.primekey.se/Services/Support/ http://www.primekey.se/Services/Training/ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ SignServer-develop mailing list Sig...@li... https://lists.sourceforge.net/lists/listinfo/signserver-develop -- Antoine Louiset Tél : +33 6 76 66 80 34 Responsable du projet Yousign Mail : ant...@yo... |
|
From: Antoine L. <ant...@yo...> - 2012-08-01 02:47:17
|
Hi Markus, Thanks for your answer. It's ok for me, do you think it will resolve the last error : no active worker available ? Best regards, Antoine Le 31/07/2012 20:37, Markus Kilås a écrit : > Hi Antoine, > > I finally found it. > > It was there in the change log for the next release all the time, not > sure how I could miss it. Anyway, the certificate was renewed as part > of https://jira.primekey.se/browse/DSS-483 and the issue was already > resolved in the 3.2 branch and will be available in the next release > (SignServer 3.2.3). > > Best regards, > Markus > > > On 2012-07-31 10:11, Antoine Louiset wrote: >> Yes, I use the version 3.2.2. >> >> Le 31/07/2012 10:04, Markus Kilås a écrit : >>> I did the same thing but I have much later dates for the >>> TestLimitKeyUsageSigner (5802). Are you really using the latest release >>> (ie. 3.2.2) otherwise upgrading should solve the problem. >>> >>> Best regards, >>> Markus >>> >>> On 2012-07-30 20:56, Antoine Louiset wrote: >>>> You were right Markus (as always ! ) ! >>>> >>>> I have got 2 errors and one fail. I join a screenshot of the admin gui >>>> (in the reports.rar file). After launching the tests, we can see that >>>> the worker 5802 and others are unavailable. >>>> >>>> After removing this worker, I launch bin/signserver.sh setproperties >>>> modules/SignServer-Module-XMLSigner/src/conf/junittest-part-config.properties >>>> >>>> to activate its and then the reload command. >>>> >>>> We can see in the Capture-1.png the result. The signer certificate is >>>> indeed valid until 20/04/12. >>>> >>>> After resolving this problem, there will be one last error !! >>>> >>>> Have a nice evening. >>>> >>>> Best regards, >>>> >>>> Le 30/07/2012 19:05, Markus Kilås a écrit : >>>>> I am not able to reproduce the test failure you are getting. I also >>>>> checked the certificate for worker 5802 and it should not expire >>>>> until >>>>> year 2021 so it is a very strange error message. >>>>> >>>>> Have you tried clearing th database before running the tests in case >>>>> some signers are left from previous test runs? >>>>> >>>>> Best regards, >>>>> Markus >>>>> >>>>> On 2012-07-30 16:54, Antoine Louiset wrote: >>>>>> Ok Markus, no problem ! Thanks ! >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Antoine >>>>>> >>>>>> Le 30/07/2012 16:53, Markus Kilås a écrit : >>>>>>> On 2012-07-30 15:08, Antoine Louiset wrote: >>>>>>>> Hi Markus, >>>>>>>> >>>>>>>> Thanks for your fast answer ! >>>>>>>> >>>>>>>> I have just one remark for the JCE installation. I don't find >>>>>>>> it in >>>>>>>> the >>>>>>>> installation guide (I read it quickly). >>>>>>> I was really surprised it wasn't there. I have registered >>>>>>> https://jira.primekey.se/browse/DSS-514. >>>>>>> >>>>>>>> I download JCE policy and it resolves one fail. The problem of the >>>>>>>> signer 5802 will resolve one fail and one error. So there will >>>>>>>> be no >>>>>>>> more fails but I have no idea about the other errors. What do you >>>>>>>> think >>>>>>>> about them ? >>>>>>> I will try to get back about them. I haven't yet had to time to >>>>>>> test it >>>>>>> on my machine. >>>>>>> >>>>>>> Best regards, >>>>>>> Markus >>>>>>> >>>>>>>> Good afternoon ! >>>>>>>> >>>>>>>> >>>>>>>> Antoine >>>>>>>> >>>>>>>> Le 30/07/2012 10:47, Markus Kilås a écrit : >>>>>>>>> Hi Antoine, >>>>>>>>> >>>>>>>>> See answers below. >>>>>>>>> >>>>>>>>> On 2012-07-28 23:24, Antoine Louiset wrote: >>>>>>>>>> Hi Markus, >>>>>>>>>> >>>>>>>>>> The p12 directory seems to be used to set truststore >>>>>>>>>> certificates >>>>>>>>>> for >>>>>>>>>> JBoss (see >>>>>>>>>> http://signserver.org/manual/complete.en.html#4.%20Configure%20web%20server%20keystores) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> but I think this truststore is just used in the tests of >>>>>>>>>> signserver >>>>>>>>>> and >>>>>>>>>> could be used for the java trust keystore. Jboss and >>>>>>>>>> glassfish have >>>>>>>>>> their own truststore and keystore, why don't you use them ? >>>>>>>>> That is correct. The truststore in the p12 folder is used both by >>>>>>>>> JBoss >>>>>>>>> and the tests. So if you are going to run the tests you can put a >>>>>>>>> truststore in the p12 folder. I believe the reason for >>>>>>>>> handling it >>>>>>>>> this >>>>>>>>> way is that different application servers have different >>>>>>>>> locations >>>>>>>>> for >>>>>>>>> the truststore and the tests would not know where to find it. >>>>>>>>> In fact >>>>>>>>> where JBoss finds it depends on what is written in the >>>>>>>>> server.xml, >>>>>>>>> so it >>>>>>>>> could also be different if SignServer isn't used for deploying >>>>>>>>> it. >>>>>>>>> The >>>>>>>>> solution we use, to not depend on different application >>>>>>>>> servers and >>>>>>>>> configurations is to decide that it should be placed in the p12 >>>>>>>>> folder >>>>>>>>> of SignServer. >>>>>>>>> >>>>>>>>>> In the signserver_build.properties file, there are several >>>>>>>>>> properties >>>>>>>>>> which are written for the use of JBoss but we do not know if >>>>>>>>>> they >>>>>>>>>> are >>>>>>>>>> needed for Glassfish : httpsserver.bindaddress.* | >>>>>>>>>> database.url | >>>>>>>>>> deploy.hostname.node* >>>>>>>>> Some are explained in the installation guide, such as >>>>>>>>> "database.url" >>>>>>>>> which is said to be used by JBoss and some comments talks about >>>>>>>>> JBoss in >>>>>>>>> the sample configuration file. But the documentation is >>>>>>>>> lacking for >>>>>>>>> many >>>>>>>>> of the other properties in this aspect. >>>>>>>>> >>>>>>>>>> What is the aim of deploy.ssh.* properties ? >>>>>>>>> I think the idea is to be able to deploy to a remote server by >>>>>>>>> transferring the files (signserver.ear etc) over SSH. Not sure if >>>>>>>>> it is >>>>>>>>> working though as I can not find any documentation about it. >>>>>>>>> You are >>>>>>>>> very welcome to test it out if you want and let us know if it is >>>>>>>>> working. If not we might consider either fixing it and adding >>>>>>>>> documentation for it or remove it. >>>>>>>>> >>>>>>>>>> Why j2ee.web-nohttps has to be set to true to launch the >>>>>>>>>> tests while >>>>>>>>>> https is used in these tests ? >>>>>>>>> j2ee.web-nohttps is controlling wither the keystores and >>>>>>>>> truststores >>>>>>>>> should be deployed (to JBoss) or not. The tests should not >>>>>>>>> depend on >>>>>>>>> this setting so if it says somewhere that it must be set to >>>>>>>>> true I >>>>>>>>> would >>>>>>>>> suspect that to be a bug in the documentation. Please report a >>>>>>>>> bug >>>>>>>>> with >>>>>>>>> where you seen it in that case. >>>>>>>>> >>>>>>>>>> The most important thing for me today is tests ! I run them, I >>>>>>>>>> resolve >>>>>>>>>> the problem about trustanchors. I join the results, I do not >>>>>>>>>> understand >>>>>>>>>> the errors and the fails, have you ever seen them ? >>>>>>>>> From the test report you attached I can see two different >>>>>>>>> failures >>>>>>>>> which >>>>>>>>> probably is also the cause of all the errors. >>>>>>>>> 1. ExtendedHardCodedCryptoTokenTest testStrongCryptoAvailable >>>>>>>>> JCE crypto policy was not installed as the key length was limited >>>>>>>>> expected:<2147483647> but was:<64> >>>>>>>>> >>>>>>>>> This means that you are running the Oracle JDK and have not >>>>>>>>> installed >>>>>>>>> JCE crypto policy. See the installation guide. >>>>>>>>> >>>>>>>>> 2. LimitKeyUsagesTest test01Limit Error Signer 5802 expired at >>>>>>>>> Fri >>>>>>>>> Apr >>>>>>>>> 20 16:18:57 CEST 2012 >>>>>>>>> Looks like the demo signer certificate used has expired. I will >>>>>>>>> run the >>>>>>>>> tests on your continues integration server and see if we have the >>>>>>>>> same >>>>>>>>> problem there. They might just have to be renewed. >>>>>>>>> >>>>>>>>>> How can I send my script to install signserver ? >>>>>>>>> If it is less then 40 KB you can just send it to the mailing >>>>>>>>> list, >>>>>>>>> otherwise try to upload it somewhere and send the link or send it >>>>>>>>> directly to me. >>>>>>>>> >>>>>>>>>> I take this mail to congratulate you and your team for this >>>>>>>>>> project >>>>>>>>>> which is really good. >>>>>>>>> Thanks to you for reporting the issues you find. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Markus >>>>>>>>> >>>>>>>>>> Have a nice weekend. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> >>>>> >>> >>> >> >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> >> >> _______________________________________________ >> SignServer-develop mailing list >> Sig...@li... >> https://lists.sourceforge.net/lists/listinfo/signserver-develop > > > -- > > PrimeKey Solutions offers a commercial EJBCA support subscription and training for EJBCA. Please seewww.primekey.se or con...@pr... for more information. > http://www.primekey.se/Services/Support/ > http://www.primekey.se/Services/Training/ > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > _______________________________________________ > SignServer-develop mailing list > Sig...@li... > https://lists.sourceforge.net/lists/listinfo/signserver-develop -- Antoine Louiset Tél : +33 6 76 66 80 34 Responsable du projet Yousign Mail : ant...@yo... |
|
From: Markus K. <ejb...@pr...> - 2012-07-31 18:37:39
|
Hi Antoine, I finally found it. It was there in the change log for the next release all the time, not sure how I could miss it. Anyway, the certificate was renewed as part of https://jira.primekey.se/browse/DSS-483 and the issue was already resolved in the 3.2 branch and will be available in the next release (SignServer 3.2.3). Best regards, Markus On 2012-07-31 10:11, Antoine Louiset wrote: > Yes, I use the version 3.2.2. > > Le 31/07/2012 10:04, Markus Kilås a écrit : >> I did the same thing but I have much later dates for the >> TestLimitKeyUsageSigner (5802). Are you really using the latest release >> (ie. 3.2.2) otherwise upgrading should solve the problem. >> >> Best regards, >> Markus >> >> On 2012-07-30 20:56, Antoine Louiset wrote: >>> You were right Markus (as always ! ) ! >>> >>> I have got 2 errors and one fail. I join a screenshot of the admin gui >>> (in the reports.rar file). After launching the tests, we can see that >>> the worker 5802 and others are unavailable. >>> >>> After removing this worker, I launch bin/signserver.sh setproperties >>> modules/SignServer-Module-XMLSigner/src/conf/junittest-part-config.properties >>> >>> to activate its and then the reload command. >>> >>> We can see in the Capture-1.png the result. The signer certificate is >>> indeed valid until 20/04/12. >>> >>> After resolving this problem, there will be one last error !! >>> >>> Have a nice evening. >>> >>> Best regards, >>> >>> Le 30/07/2012 19:05, Markus Kilås a écrit : >>>> I am not able to reproduce the test failure you are getting. I also >>>> checked the certificate for worker 5802 and it should not expire until >>>> year 2021 so it is a very strange error message. >>>> >>>> Have you tried clearing th database before running the tests in case >>>> some signers are left from previous test runs? >>>> >>>> Best regards, >>>> Markus >>>> >>>> On 2012-07-30 16:54, Antoine Louiset wrote: >>>>> Ok Markus, no problem ! Thanks ! >>>>> >>>>> Best regards, >>>>> >>>>> Antoine >>>>> >>>>> Le 30/07/2012 16:53, Markus Kilås a écrit : >>>>>> On 2012-07-30 15:08, Antoine Louiset wrote: >>>>>>> Hi Markus, >>>>>>> >>>>>>> Thanks for your fast answer ! >>>>>>> >>>>>>> I have just one remark for the JCE installation. I don't find it in >>>>>>> the >>>>>>> installation guide (I read it quickly). >>>>>> I was really surprised it wasn't there. I have registered >>>>>> https://jira.primekey.se/browse/DSS-514. >>>>>> >>>>>>> I download JCE policy and it resolves one fail. The problem of the >>>>>>> signer 5802 will resolve one fail and one error. So there will >>>>>>> be no >>>>>>> more fails but I have no idea about the other errors. What do you >>>>>>> think >>>>>>> about them ? >>>>>> I will try to get back about them. I haven't yet had to time to >>>>>> test it >>>>>> on my machine. >>>>>> >>>>>> Best regards, >>>>>> Markus >>>>>> >>>>>>> Good afternoon ! >>>>>>> >>>>>>> >>>>>>> Antoine >>>>>>> >>>>>>> Le 30/07/2012 10:47, Markus Kilås a écrit : >>>>>>>> Hi Antoine, >>>>>>>> >>>>>>>> See answers below. >>>>>>>> >>>>>>>> On 2012-07-28 23:24, Antoine Louiset wrote: >>>>>>>>> Hi Markus, >>>>>>>>> >>>>>>>>> The p12 directory seems to be used to set truststore certificates >>>>>>>>> for >>>>>>>>> JBoss (see >>>>>>>>> http://signserver.org/manual/complete.en.html#4.%20Configure%20web%20server%20keystores) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> but I think this truststore is just used in the tests of >>>>>>>>> signserver >>>>>>>>> and >>>>>>>>> could be used for the java trust keystore. Jboss and glassfish >>>>>>>>> have >>>>>>>>> their own truststore and keystore, why don't you use them ? >>>>>>>> That is correct. The truststore in the p12 folder is used both by >>>>>>>> JBoss >>>>>>>> and the tests. So if you are going to run the tests you can put a >>>>>>>> truststore in the p12 folder. I believe the reason for handling it >>>>>>>> this >>>>>>>> way is that different application servers have different locations >>>>>>>> for >>>>>>>> the truststore and the tests would not know where to find it. >>>>>>>> In fact >>>>>>>> where JBoss finds it depends on what is written in the server.xml, >>>>>>>> so it >>>>>>>> could also be different if SignServer isn't used for deploying it. >>>>>>>> The >>>>>>>> solution we use, to not depend on different application servers >>>>>>>> and >>>>>>>> configurations is to decide that it should be placed in the p12 >>>>>>>> folder >>>>>>>> of SignServer. >>>>>>>> >>>>>>>>> In the signserver_build.properties file, there are several >>>>>>>>> properties >>>>>>>>> which are written for the use of JBoss but we do not know if they >>>>>>>>> are >>>>>>>>> needed for Glassfish : httpsserver.bindaddress.* | database.url | >>>>>>>>> deploy.hostname.node* >>>>>>>> Some are explained in the installation guide, such as >>>>>>>> "database.url" >>>>>>>> which is said to be used by JBoss and some comments talks about >>>>>>>> JBoss in >>>>>>>> the sample configuration file. But the documentation is lacking >>>>>>>> for >>>>>>>> many >>>>>>>> of the other properties in this aspect. >>>>>>>> >>>>>>>>> What is the aim of deploy.ssh.* properties ? >>>>>>>> I think the idea is to be able to deploy to a remote server by >>>>>>>> transferring the files (signserver.ear etc) over SSH. Not sure if >>>>>>>> it is >>>>>>>> working though as I can not find any documentation about it. >>>>>>>> You are >>>>>>>> very welcome to test it out if you want and let us know if it is >>>>>>>> working. If not we might consider either fixing it and adding >>>>>>>> documentation for it or remove it. >>>>>>>> >>>>>>>>> Why j2ee.web-nohttps has to be set to true to launch the tests >>>>>>>>> while >>>>>>>>> https is used in these tests ? >>>>>>>> j2ee.web-nohttps is controlling wither the keystores and >>>>>>>> truststores >>>>>>>> should be deployed (to JBoss) or not. The tests should not >>>>>>>> depend on >>>>>>>> this setting so if it says somewhere that it must be set to true I >>>>>>>> would >>>>>>>> suspect that to be a bug in the documentation. Please report a bug >>>>>>>> with >>>>>>>> where you seen it in that case. >>>>>>>> >>>>>>>>> The most important thing for me today is tests ! I run them, I >>>>>>>>> resolve >>>>>>>>> the problem about trustanchors. I join the results, I do not >>>>>>>>> understand >>>>>>>>> the errors and the fails, have you ever seen them ? >>>>>>>> From the test report you attached I can see two different >>>>>>>> failures >>>>>>>> which >>>>>>>> probably is also the cause of all the errors. >>>>>>>> 1. ExtendedHardCodedCryptoTokenTest testStrongCryptoAvailable >>>>>>>> JCE crypto policy was not installed as the key length was limited >>>>>>>> expected:<2147483647> but was:<64> >>>>>>>> >>>>>>>> This means that you are running the Oracle JDK and have not >>>>>>>> installed >>>>>>>> JCE crypto policy. See the installation guide. >>>>>>>> >>>>>>>> 2. LimitKeyUsagesTest test01Limit Error Signer 5802 expired at Fri >>>>>>>> Apr >>>>>>>> 20 16:18:57 CEST 2012 >>>>>>>> Looks like the demo signer certificate used has expired. I will >>>>>>>> run the >>>>>>>> tests on your continues integration server and see if we have the >>>>>>>> same >>>>>>>> problem there. They might just have to be renewed. >>>>>>>> >>>>>>>>> How can I send my script to install signserver ? >>>>>>>> If it is less then 40 KB you can just send it to the mailing list, >>>>>>>> otherwise try to upload it somewhere and send the link or send it >>>>>>>> directly to me. >>>>>>>> >>>>>>>>> I take this mail to congratulate you and your team for this >>>>>>>>> project >>>>>>>>> which is really good. >>>>>>>> Thanks to you for reporting the issues you find. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Markus >>>>>>>> >>>>>>>>> Have a nice weekend. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>> >> >> > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > _______________________________________________ > SignServer-develop mailing list > Sig...@li... > https://lists.sourceforge.net/lists/listinfo/signserver-develop -- PrimeKey Solutions offers a commercial EJBCA support subscription and training for EJBCA. Please see www.primekey.se or contact in...@pr... for more information. http://www.primekey.se/Services/Support/ http://www.primekey.se/Services/Training/ |
|
From: Antoine L. <ant...@yo...> - 2012-07-31 08:11:29
|
Yes, I use the version 3.2.2. Le 31/07/2012 10:04, Markus Kilås a écrit : > I did the same thing but I have much later dates for the > TestLimitKeyUsageSigner (5802). Are you really using the latest release > (ie. 3.2.2) otherwise upgrading should solve the problem. > > Best regards, > Markus > > On 2012-07-30 20:56, Antoine Louiset wrote: >> You were right Markus (as always ! ) ! >> >> I have got 2 errors and one fail. I join a screenshot of the admin gui >> (in the reports.rar file). After launching the tests, we can see that >> the worker 5802 and others are unavailable. >> >> After removing this worker, I launch bin/signserver.sh setproperties >> modules/SignServer-Module-XMLSigner/src/conf/junittest-part-config.properties >> to activate its and then the reload command. >> >> We can see in the Capture-1.png the result. The signer certificate is >> indeed valid until 20/04/12. >> >> After resolving this problem, there will be one last error !! >> >> Have a nice evening. >> >> Best regards, >> >> Le 30/07/2012 19:05, Markus Kilås a écrit : >>> I am not able to reproduce the test failure you are getting. I also >>> checked the certificate for worker 5802 and it should not expire until >>> year 2021 so it is a very strange error message. >>> >>> Have you tried clearing th database before running the tests in case >>> some signers are left from previous test runs? >>> >>> Best regards, >>> Markus >>> >>> On 2012-07-30 16:54, Antoine Louiset wrote: >>>> Ok Markus, no problem ! Thanks ! >>>> >>>> Best regards, >>>> >>>> Antoine >>>> >>>> Le 30/07/2012 16:53, Markus Kilås a écrit : >>>>> On 2012-07-30 15:08, Antoine Louiset wrote: >>>>>> Hi Markus, >>>>>> >>>>>> Thanks for your fast answer ! >>>>>> >>>>>> I have just one remark for the JCE installation. I don't find it in >>>>>> the >>>>>> installation guide (I read it quickly). >>>>> I was really surprised it wasn't there. I have registered >>>>> https://jira.primekey.se/browse/DSS-514. >>>>> >>>>>> I download JCE policy and it resolves one fail. The problem of the >>>>>> signer 5802 will resolve one fail and one error. So there will be no >>>>>> more fails but I have no idea about the other errors. What do you >>>>>> think >>>>>> about them ? >>>>> I will try to get back about them. I haven't yet had to time to test it >>>>> on my machine. >>>>> >>>>> Best regards, >>>>> Markus >>>>> >>>>>> Good afternoon ! >>>>>> >>>>>> >>>>>> Antoine >>>>>> >>>>>> Le 30/07/2012 10:47, Markus Kilås a écrit : >>>>>>> Hi Antoine, >>>>>>> >>>>>>> See answers below. >>>>>>> >>>>>>> On 2012-07-28 23:24, Antoine Louiset wrote: >>>>>>>> Hi Markus, >>>>>>>> >>>>>>>> The p12 directory seems to be used to set truststore certificates >>>>>>>> for >>>>>>>> JBoss (see >>>>>>>> http://signserver.org/manual/complete.en.html#4.%20Configure%20web%20server%20keystores) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> but I think this truststore is just used in the tests of signserver >>>>>>>> and >>>>>>>> could be used for the java trust keystore. Jboss and glassfish have >>>>>>>> their own truststore and keystore, why don't you use them ? >>>>>>> That is correct. The truststore in the p12 folder is used both by >>>>>>> JBoss >>>>>>> and the tests. So if you are going to run the tests you can put a >>>>>>> truststore in the p12 folder. I believe the reason for handling it >>>>>>> this >>>>>>> way is that different application servers have different locations >>>>>>> for >>>>>>> the truststore and the tests would not know where to find it. In fact >>>>>>> where JBoss finds it depends on what is written in the server.xml, >>>>>>> so it >>>>>>> could also be different if SignServer isn't used for deploying it. >>>>>>> The >>>>>>> solution we use, to not depend on different application servers and >>>>>>> configurations is to decide that it should be placed in the p12 >>>>>>> folder >>>>>>> of SignServer. >>>>>>> >>>>>>>> In the signserver_build.properties file, there are several >>>>>>>> properties >>>>>>>> which are written for the use of JBoss but we do not know if they >>>>>>>> are >>>>>>>> needed for Glassfish : httpsserver.bindaddress.* | database.url | >>>>>>>> deploy.hostname.node* >>>>>>> Some are explained in the installation guide, such as "database.url" >>>>>>> which is said to be used by JBoss and some comments talks about >>>>>>> JBoss in >>>>>>> the sample configuration file. But the documentation is lacking for >>>>>>> many >>>>>>> of the other properties in this aspect. >>>>>>> >>>>>>>> What is the aim of deploy.ssh.* properties ? >>>>>>> I think the idea is to be able to deploy to a remote server by >>>>>>> transferring the files (signserver.ear etc) over SSH. Not sure if >>>>>>> it is >>>>>>> working though as I can not find any documentation about it. You are >>>>>>> very welcome to test it out if you want and let us know if it is >>>>>>> working. If not we might consider either fixing it and adding >>>>>>> documentation for it or remove it. >>>>>>> >>>>>>>> Why j2ee.web-nohttps has to be set to true to launch the tests while >>>>>>>> https is used in these tests ? >>>>>>> j2ee.web-nohttps is controlling wither the keystores and truststores >>>>>>> should be deployed (to JBoss) or not. The tests should not depend on >>>>>>> this setting so if it says somewhere that it must be set to true I >>>>>>> would >>>>>>> suspect that to be a bug in the documentation. Please report a bug >>>>>>> with >>>>>>> where you seen it in that case. >>>>>>> >>>>>>>> The most important thing for me today is tests ! I run them, I >>>>>>>> resolve >>>>>>>> the problem about trustanchors. I join the results, I do not >>>>>>>> understand >>>>>>>> the errors and the fails, have you ever seen them ? >>>>>>> From the test report you attached I can see two different failures >>>>>>> which >>>>>>> probably is also the cause of all the errors. >>>>>>> 1. ExtendedHardCodedCryptoTokenTest testStrongCryptoAvailable >>>>>>> JCE crypto policy was not installed as the key length was limited >>>>>>> expected:<2147483647> but was:<64> >>>>>>> >>>>>>> This means that you are running the Oracle JDK and have not installed >>>>>>> JCE crypto policy. See the installation guide. >>>>>>> >>>>>>> 2. LimitKeyUsagesTest test01Limit Error Signer 5802 expired at Fri >>>>>>> Apr >>>>>>> 20 16:18:57 CEST 2012 >>>>>>> Looks like the demo signer certificate used has expired. I will >>>>>>> run the >>>>>>> tests on your continues integration server and see if we have the >>>>>>> same >>>>>>> problem there. They might just have to be renewed. >>>>>>> >>>>>>>> How can I send my script to install signserver ? >>>>>>> If it is less then 40 KB you can just send it to the mailing list, >>>>>>> otherwise try to upload it somewhere and send the link or send it >>>>>>> directly to me. >>>>>>> >>>>>>>> I take this mail to congratulate you and your team for this project >>>>>>>> which is really good. >>>>>>> Thanks to you for reporting the issues you find. >>>>>>> >>>>>>> Best regards, >>>>>>> Markus >>>>>>> >>>>>>>> Have a nice weekend. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>> > > -- Antoine Louiset Tél : +33 6 76 66 80 34 Responsable du projet Yousign Mail : ant...@yo... |
|
From: Markus K. <ma...@pr...> - 2012-07-31 08:04:54
|
I did the same thing but I have much later dates for the TestLimitKeyUsageSigner (5802). Are you really using the latest release (ie. 3.2.2) otherwise upgrading should solve the problem. Best regards, Markus On 2012-07-30 20:56, Antoine Louiset wrote: > You were right Markus (as always ! ) ! > > I have got 2 errors and one fail. I join a screenshot of the admin gui > (in the reports.rar file). After launching the tests, we can see that > the worker 5802 and others are unavailable. > > After removing this worker, I launch bin/signserver.sh setproperties > modules/SignServer-Module-XMLSigner/src/conf/junittest-part-config.properties > to activate its and then the reload command. > > We can see in the Capture-1.png the result. The signer certificate is > indeed valid until 20/04/12. > > After resolving this problem, there will be one last error !! > > Have a nice evening. > > Best regards, > > Le 30/07/2012 19:05, Markus Kilås a écrit : >> I am not able to reproduce the test failure you are getting. I also >> checked the certificate for worker 5802 and it should not expire until >> year 2021 so it is a very strange error message. >> >> Have you tried clearing th database before running the tests in case >> some signers are left from previous test runs? >> >> Best regards, >> Markus >> >> On 2012-07-30 16:54, Antoine Louiset wrote: >>> Ok Markus, no problem ! Thanks ! >>> >>> Best regards, >>> >>> Antoine >>> >>> Le 30/07/2012 16:53, Markus Kilås a écrit : >>>> On 2012-07-30 15:08, Antoine Louiset wrote: >>>>> Hi Markus, >>>>> >>>>> Thanks for your fast answer ! >>>>> >>>>> I have just one remark for the JCE installation. I don't find it in >>>>> the >>>>> installation guide (I read it quickly). >>>> I was really surprised it wasn't there. I have registered >>>> https://jira.primekey.se/browse/DSS-514. >>>> >>>>> I download JCE policy and it resolves one fail. The problem of the >>>>> signer 5802 will resolve one fail and one error. So there will be no >>>>> more fails but I have no idea about the other errors. What do you >>>>> think >>>>> about them ? >>>> I will try to get back about them. I haven't yet had to time to test it >>>> on my machine. >>>> >>>> Best regards, >>>> Markus >>>> >>>>> Good afternoon ! >>>>> >>>>> >>>>> Antoine >>>>> >>>>> Le 30/07/2012 10:47, Markus Kilås a écrit : >>>>>> Hi Antoine, >>>>>> >>>>>> See answers below. >>>>>> >>>>>> On 2012-07-28 23:24, Antoine Louiset wrote: >>>>>>> Hi Markus, >>>>>>> >>>>>>> The p12 directory seems to be used to set truststore certificates >>>>>>> for >>>>>>> JBoss (see >>>>>>> http://signserver.org/manual/complete.en.html#4.%20Configure%20web%20server%20keystores) >>>>>>> >>>>>>> >>>>>>> >>>>>>> but I think this truststore is just used in the tests of signserver >>>>>>> and >>>>>>> could be used for the java trust keystore. Jboss and glassfish have >>>>>>> their own truststore and keystore, why don't you use them ? >>>>>> That is correct. The truststore in the p12 folder is used both by >>>>>> JBoss >>>>>> and the tests. So if you are going to run the tests you can put a >>>>>> truststore in the p12 folder. I believe the reason for handling it >>>>>> this >>>>>> way is that different application servers have different locations >>>>>> for >>>>>> the truststore and the tests would not know where to find it. In fact >>>>>> where JBoss finds it depends on what is written in the server.xml, >>>>>> so it >>>>>> could also be different if SignServer isn't used for deploying it. >>>>>> The >>>>>> solution we use, to not depend on different application servers and >>>>>> configurations is to decide that it should be placed in the p12 >>>>>> folder >>>>>> of SignServer. >>>>>> >>>>>>> In the signserver_build.properties file, there are several >>>>>>> properties >>>>>>> which are written for the use of JBoss but we do not know if they >>>>>>> are >>>>>>> needed for Glassfish : httpsserver.bindaddress.* | database.url | >>>>>>> deploy.hostname.node* >>>>>> Some are explained in the installation guide, such as "database.url" >>>>>> which is said to be used by JBoss and some comments talks about >>>>>> JBoss in >>>>>> the sample configuration file. But the documentation is lacking for >>>>>> many >>>>>> of the other properties in this aspect. >>>>>> >>>>>>> What is the aim of deploy.ssh.* properties ? >>>>>> I think the idea is to be able to deploy to a remote server by >>>>>> transferring the files (signserver.ear etc) over SSH. Not sure if >>>>>> it is >>>>>> working though as I can not find any documentation about it. You are >>>>>> very welcome to test it out if you want and let us know if it is >>>>>> working. If not we might consider either fixing it and adding >>>>>> documentation for it or remove it. >>>>>> >>>>>>> Why j2ee.web-nohttps has to be set to true to launch the tests while >>>>>>> https is used in these tests ? >>>>>> j2ee.web-nohttps is controlling wither the keystores and truststores >>>>>> should be deployed (to JBoss) or not. The tests should not depend on >>>>>> this setting so if it says somewhere that it must be set to true I >>>>>> would >>>>>> suspect that to be a bug in the documentation. Please report a bug >>>>>> with >>>>>> where you seen it in that case. >>>>>> >>>>>>> The most important thing for me today is tests ! I run them, I >>>>>>> resolve >>>>>>> the problem about trustanchors. I join the results, I do not >>>>>>> understand >>>>>>> the errors and the fails, have you ever seen them ? >>>>>> From the test report you attached I can see two different failures >>>>>> which >>>>>> probably is also the cause of all the errors. >>>>>> 1. ExtendedHardCodedCryptoTokenTest testStrongCryptoAvailable >>>>>> JCE crypto policy was not installed as the key length was limited >>>>>> expected:<2147483647> but was:<64> >>>>>> >>>>>> This means that you are running the Oracle JDK and have not installed >>>>>> JCE crypto policy. See the installation guide. >>>>>> >>>>>> 2. LimitKeyUsagesTest test01Limit Error Signer 5802 expired at Fri >>>>>> Apr >>>>>> 20 16:18:57 CEST 2012 >>>>>> Looks like the demo signer certificate used has expired. I will >>>>>> run the >>>>>> tests on your continues integration server and see if we have the >>>>>> same >>>>>> problem there. They might just have to be renewed. >>>>>> >>>>>>> How can I send my script to install signserver ? >>>>>> If it is less then 40 KB you can just send it to the mailing list, >>>>>> otherwise try to upload it somewhere and send the link or send it >>>>>> directly to me. >>>>>> >>>>>>> I take this mail to congratulate you and your team for this project >>>>>>> which is really good. >>>>>> Thanks to you for reporting the issues you find. >>>>>> >>>>>> Best regards, >>>>>> Markus >>>>>> >>>>>>> Have a nice weekend. >>>>>>> >>>>>>> Best regards, >>>>>>> >>>> >> >> > -- Kind regards, Markus Kilås Security Consultant & Developer PrimeKey Solutions AB Anderstorpsv. 16 171 54 Solna Sweden Phone: +46 70 424 94 85 Skype: markusatskype Email: mar...@pr... www.primekey.se |
|
From: Antoine L. <ant...@yo...> - 2012-07-30 18:57:33
|
You were right Markus (as always ! ) ! I have got 2 errors and one fail. I join a screenshot of the admin gui (in the reports.rar file). After launching the tests, we can see that the worker 5802 and others are unavailable. After removing this worker, I launch bin/signserver.sh setproperties modules/SignServer-Module-XMLSigner/src/conf/junittest-part-config.properties to activate its and then the reload command. We can see in the Capture-1.png the result. The signer certificate is indeed valid until 20/04/12. After resolving this problem, there will be one last error !! Have a nice evening. Best regards, Le 30/07/2012 19:05, Markus Kilås a écrit : > I am not able to reproduce the test failure you are getting. I also > checked the certificate for worker 5802 and it should not expire until > year 2021 so it is a very strange error message. > > Have you tried clearing th database before running the tests in case > some signers are left from previous test runs? > > Best regards, > Markus > > On 2012-07-30 16:54, Antoine Louiset wrote: >> Ok Markus, no problem ! Thanks ! >> >> Best regards, >> >> Antoine >> >> Le 30/07/2012 16:53, Markus Kilås a écrit : >>> On 2012-07-30 15:08, Antoine Louiset wrote: >>>> Hi Markus, >>>> >>>> Thanks for your fast answer ! >>>> >>>> I have just one remark for the JCE installation. I don't find it in the >>>> installation guide (I read it quickly). >>> I was really surprised it wasn't there. I have registered >>> https://jira.primekey.se/browse/DSS-514. >>> >>>> I download JCE policy and it resolves one fail. The problem of the >>>> signer 5802 will resolve one fail and one error. So there will be no >>>> more fails but I have no idea about the other errors. What do you think >>>> about them ? >>> I will try to get back about them. I haven't yet had to time to test it >>> on my machine. >>> >>> Best regards, >>> Markus >>> >>>> Good afternoon ! >>>> >>>> >>>> Antoine >>>> >>>> Le 30/07/2012 10:47, Markus Kilås a écrit : >>>>> Hi Antoine, >>>>> >>>>> See answers below. >>>>> >>>>> On 2012-07-28 23:24, Antoine Louiset wrote: >>>>>> Hi Markus, >>>>>> >>>>>> The p12 directory seems to be used to set truststore certificates for >>>>>> JBoss (see >>>>>> http://signserver.org/manual/complete.en.html#4.%20Configure%20web%20server%20keystores) >>>>>> >>>>>> >>>>>> but I think this truststore is just used in the tests of signserver >>>>>> and >>>>>> could be used for the java trust keystore. Jboss and glassfish have >>>>>> their own truststore and keystore, why don't you use them ? >>>>> That is correct. The truststore in the p12 folder is used both by JBoss >>>>> and the tests. So if you are going to run the tests you can put a >>>>> truststore in the p12 folder. I believe the reason for handling it this >>>>> way is that different application servers have different locations for >>>>> the truststore and the tests would not know where to find it. In fact >>>>> where JBoss finds it depends on what is written in the server.xml, >>>>> so it >>>>> could also be different if SignServer isn't used for deploying it. The >>>>> solution we use, to not depend on different application servers and >>>>> configurations is to decide that it should be placed in the p12 folder >>>>> of SignServer. >>>>> >>>>>> In the signserver_build.properties file, there are several properties >>>>>> which are written for the use of JBoss but we do not know if they are >>>>>> needed for Glassfish : httpsserver.bindaddress.* | database.url | >>>>>> deploy.hostname.node* >>>>> Some are explained in the installation guide, such as "database.url" >>>>> which is said to be used by JBoss and some comments talks about >>>>> JBoss in >>>>> the sample configuration file. But the documentation is lacking for >>>>> many >>>>> of the other properties in this aspect. >>>>> >>>>>> What is the aim of deploy.ssh.* properties ? >>>>> I think the idea is to be able to deploy to a remote server by >>>>> transferring the files (signserver.ear etc) over SSH. Not sure if it is >>>>> working though as I can not find any documentation about it. You are >>>>> very welcome to test it out if you want and let us know if it is >>>>> working. If not we might consider either fixing it and adding >>>>> documentation for it or remove it. >>>>> >>>>>> Why j2ee.web-nohttps has to be set to true to launch the tests while >>>>>> https is used in these tests ? >>>>> j2ee.web-nohttps is controlling wither the keystores and truststores >>>>> should be deployed (to JBoss) or not. The tests should not depend on >>>>> this setting so if it says somewhere that it must be set to true I >>>>> would >>>>> suspect that to be a bug in the documentation. Please report a bug with >>>>> where you seen it in that case. >>>>> >>>>>> The most important thing for me today is tests ! I run them, I resolve >>>>>> the problem about trustanchors. I join the results, I do not >>>>>> understand >>>>>> the errors and the fails, have you ever seen them ? >>>>> From the test report you attached I can see two different failures >>>>> which >>>>> probably is also the cause of all the errors. >>>>> 1. ExtendedHardCodedCryptoTokenTest testStrongCryptoAvailable >>>>> JCE crypto policy was not installed as the key length was limited >>>>> expected:<2147483647> but was:<64> >>>>> >>>>> This means that you are running the Oracle JDK and have not installed >>>>> JCE crypto policy. See the installation guide. >>>>> >>>>> 2. LimitKeyUsagesTest test01Limit Error Signer 5802 expired at Fri Apr >>>>> 20 16:18:57 CEST 2012 >>>>> Looks like the demo signer certificate used has expired. I will run the >>>>> tests on your continues integration server and see if we have the same >>>>> problem there. They might just have to be renewed. >>>>> >>>>>> How can I send my script to install signserver ? >>>>> If it is less then 40 KB you can just send it to the mailing list, >>>>> otherwise try to upload it somewhere and send the link or send it >>>>> directly to me. >>>>> >>>>>> I take this mail to congratulate you and your team for this project >>>>>> which is really good. >>>>> Thanks to you for reporting the issues you find. >>>>> >>>>> Best regards, >>>>> Markus >>>>> >>>>>> Have a nice weekend. >>>>>> >>>>>> Best regards, >>>>>> >>> > > -- Antoine Louiset Tél : +33 6 76 66 80 34 Responsable du projet Yousign Mail : ant...@yo... |
|
From: Markus K. <ma...@pr...> - 2012-07-30 17:06:01
|
I am not able to reproduce the test failure you are getting. I also checked the certificate for worker 5802 and it should not expire until year 2021 so it is a very strange error message. Have you tried clearing th database before running the tests in case some signers are left from previous test runs? Best regards, Markus On 2012-07-30 16:54, Antoine Louiset wrote: > Ok Markus, no problem ! Thanks ! > > Best regards, > > Antoine > > Le 30/07/2012 16:53, Markus Kilås a écrit : >> On 2012-07-30 15:08, Antoine Louiset wrote: >>> Hi Markus, >>> >>> Thanks for your fast answer ! >>> >>> I have just one remark for the JCE installation. I don't find it in the >>> installation guide (I read it quickly). >> I was really surprised it wasn't there. I have registered >> https://jira.primekey.se/browse/DSS-514. >> >>> I download JCE policy and it resolves one fail. The problem of the >>> signer 5802 will resolve one fail and one error. So there will be no >>> more fails but I have no idea about the other errors. What do you think >>> about them ? >> I will try to get back about them. I haven't yet had to time to test it >> on my machine. >> >> Best regards, >> Markus >> >>> Good afternoon ! >>> >>> >>> Antoine >>> >>> Le 30/07/2012 10:47, Markus Kilås a écrit : >>>> Hi Antoine, >>>> >>>> See answers below. >>>> >>>> On 2012-07-28 23:24, Antoine Louiset wrote: >>>>> Hi Markus, >>>>> >>>>> The p12 directory seems to be used to set truststore certificates for >>>>> JBoss (see >>>>> http://signserver.org/manual/complete.en.html#4.%20Configure%20web%20server%20keystores) >>>>> >>>>> >>>>> but I think this truststore is just used in the tests of signserver >>>>> and >>>>> could be used for the java trust keystore. Jboss and glassfish have >>>>> their own truststore and keystore, why don't you use them ? >>>> That is correct. The truststore in the p12 folder is used both by JBoss >>>> and the tests. So if you are going to run the tests you can put a >>>> truststore in the p12 folder. I believe the reason for handling it this >>>> way is that different application servers have different locations for >>>> the truststore and the tests would not know where to find it. In fact >>>> where JBoss finds it depends on what is written in the server.xml, >>>> so it >>>> could also be different if SignServer isn't used for deploying it. The >>>> solution we use, to not depend on different application servers and >>>> configurations is to decide that it should be placed in the p12 folder >>>> of SignServer. >>>> >>>>> In the signserver_build.properties file, there are several properties >>>>> which are written for the use of JBoss but we do not know if they are >>>>> needed for Glassfish : httpsserver.bindaddress.* | database.url | >>>>> deploy.hostname.node* >>>> Some are explained in the installation guide, such as "database.url" >>>> which is said to be used by JBoss and some comments talks about >>>> JBoss in >>>> the sample configuration file. But the documentation is lacking for >>>> many >>>> of the other properties in this aspect. >>>> >>>>> What is the aim of deploy.ssh.* properties ? >>>> I think the idea is to be able to deploy to a remote server by >>>> transferring the files (signserver.ear etc) over SSH. Not sure if it is >>>> working though as I can not find any documentation about it. You are >>>> very welcome to test it out if you want and let us know if it is >>>> working. If not we might consider either fixing it and adding >>>> documentation for it or remove it. >>>> >>>>> Why j2ee.web-nohttps has to be set to true to launch the tests while >>>>> https is used in these tests ? >>>> j2ee.web-nohttps is controlling wither the keystores and truststores >>>> should be deployed (to JBoss) or not. The tests should not depend on >>>> this setting so if it says somewhere that it must be set to true I >>>> would >>>> suspect that to be a bug in the documentation. Please report a bug with >>>> where you seen it in that case. >>>> >>>>> The most important thing for me today is tests ! I run them, I resolve >>>>> the problem about trustanchors. I join the results, I do not >>>>> understand >>>>> the errors and the fails, have you ever seen them ? >>>> From the test report you attached I can see two different failures >>>> which >>>> probably is also the cause of all the errors. >>>> 1. ExtendedHardCodedCryptoTokenTest testStrongCryptoAvailable >>>> JCE crypto policy was not installed as the key length was limited >>>> expected:<2147483647> but was:<64> >>>> >>>> This means that you are running the Oracle JDK and have not installed >>>> JCE crypto policy. See the installation guide. >>>> >>>> 2. LimitKeyUsagesTest test01Limit Error Signer 5802 expired at Fri Apr >>>> 20 16:18:57 CEST 2012 >>>> Looks like the demo signer certificate used has expired. I will run the >>>> tests on your continues integration server and see if we have the same >>>> problem there. They might just have to be renewed. >>>> >>>>> How can I send my script to install signserver ? >>>> If it is less then 40 KB you can just send it to the mailing list, >>>> otherwise try to upload it somewhere and send the link or send it >>>> directly to me. >>>> >>>>> I take this mail to congratulate you and your team for this project >>>>> which is really good. >>>> Thanks to you for reporting the issues you find. >>>> >>>> Best regards, >>>> Markus >>>> >>>>> Have a nice weekend. >>>>> >>>>> Best regards, >>>>> >>>> >> >> > -- Kind regards, Markus Kilås Security Consultant & Developer PrimeKey Solutions AB Anderstorpsv. 16 171 54 Solna Sweden Phone: +46 70 424 94 85 Skype: markusatskype Email: mar...@pr... www.primekey.se |
|
From: Antoine L. <ant...@yo...> - 2012-07-30 14:55:09
|
Ok Markus, no problem ! Thanks ! Best regards, Antoine Le 30/07/2012 16:53, Markus Kilås a écrit : > On 2012-07-30 15:08, Antoine Louiset wrote: >> Hi Markus, >> >> Thanks for your fast answer ! >> >> I have just one remark for the JCE installation. I don't find it in the >> installation guide (I read it quickly). > I was really surprised it wasn't there. I have registered > https://jira.primekey.se/browse/DSS-514. > >> I download JCE policy and it resolves one fail. The problem of the >> signer 5802 will resolve one fail and one error. So there will be no >> more fails but I have no idea about the other errors. What do you think >> about them ? > I will try to get back about them. I haven't yet had to time to test it > on my machine. > > Best regards, > Markus > >> Good afternoon ! >> >> >> Antoine >> >> Le 30/07/2012 10:47, Markus Kilås a écrit : >>> Hi Antoine, >>> >>> See answers below. >>> >>> On 2012-07-28 23:24, Antoine Louiset wrote: >>>> Hi Markus, >>>> >>>> The p12 directory seems to be used to set truststore certificates for >>>> JBoss (see >>>> http://signserver.org/manual/complete.en.html#4.%20Configure%20web%20server%20keystores) >>>> >>>> but I think this truststore is just used in the tests of signserver and >>>> could be used for the java trust keystore. Jboss and glassfish have >>>> their own truststore and keystore, why don't you use them ? >>> That is correct. The truststore in the p12 folder is used both by JBoss >>> and the tests. So if you are going to run the tests you can put a >>> truststore in the p12 folder. I believe the reason for handling it this >>> way is that different application servers have different locations for >>> the truststore and the tests would not know where to find it. In fact >>> where JBoss finds it depends on what is written in the server.xml, so it >>> could also be different if SignServer isn't used for deploying it. The >>> solution we use, to not depend on different application servers and >>> configurations is to decide that it should be placed in the p12 folder >>> of SignServer. >>> >>>> In the signserver_build.properties file, there are several properties >>>> which are written for the use of JBoss but we do not know if they are >>>> needed for Glassfish : httpsserver.bindaddress.* | database.url | >>>> deploy.hostname.node* >>> Some are explained in the installation guide, such as "database.url" >>> which is said to be used by JBoss and some comments talks about JBoss in >>> the sample configuration file. But the documentation is lacking for many >>> of the other properties in this aspect. >>> >>>> What is the aim of deploy.ssh.* properties ? >>> I think the idea is to be able to deploy to a remote server by >>> transferring the files (signserver.ear etc) over SSH. Not sure if it is >>> working though as I can not find any documentation about it. You are >>> very welcome to test it out if you want and let us know if it is >>> working. If not we might consider either fixing it and adding >>> documentation for it or remove it. >>> >>>> Why j2ee.web-nohttps has to be set to true to launch the tests while >>>> https is used in these tests ? >>> j2ee.web-nohttps is controlling wither the keystores and truststores >>> should be deployed (to JBoss) or not. The tests should not depend on >>> this setting so if it says somewhere that it must be set to true I would >>> suspect that to be a bug in the documentation. Please report a bug with >>> where you seen it in that case. >>> >>>> The most important thing for me today is tests ! I run them, I resolve >>>> the problem about trustanchors. I join the results, I do not understand >>>> the errors and the fails, have you ever seen them ? >>> From the test report you attached I can see two different failures which >>> probably is also the cause of all the errors. >>> 1. ExtendedHardCodedCryptoTokenTest testStrongCryptoAvailable >>> JCE crypto policy was not installed as the key length was limited >>> expected:<2147483647> but was:<64> >>> >>> This means that you are running the Oracle JDK and have not installed >>> JCE crypto policy. See the installation guide. >>> >>> 2. LimitKeyUsagesTest test01Limit Error Signer 5802 expired at Fri Apr >>> 20 16:18:57 CEST 2012 >>> Looks like the demo signer certificate used has expired. I will run the >>> tests on your continues integration server and see if we have the same >>> problem there. They might just have to be renewed. >>> >>>> How can I send my script to install signserver ? >>> If it is less then 40 KB you can just send it to the mailing list, >>> otherwise try to upload it somewhere and send the link or send it >>> directly to me. >>> >>>> I take this mail to congratulate you and your team for this project >>>> which is really good. >>> Thanks to you for reporting the issues you find. >>> >>> Best regards, >>> Markus >>> >>>> Have a nice weekend. >>>> >>>> Best regards, >>>> >>> > > -- Antoine Louiset Tél : +33 6 76 66 80 34 Responsable du projet Yousign Mail : ant...@yo... |
|
From: Markus K. <ma...@pr...> - 2012-07-30 14:53:14
|
On 2012-07-30 15:08, Antoine Louiset wrote: > > Hi Markus, > > Thanks for your fast answer ! > > I have just one remark for the JCE installation. I don't find it in the > installation guide (I read it quickly). I was really surprised it wasn't there. I have registered https://jira.primekey.se/browse/DSS-514. > > I download JCE policy and it resolves one fail. The problem of the > signer 5802 will resolve one fail and one error. So there will be no > more fails but I have no idea about the other errors. What do you think > about them ? I will try to get back about them. I haven't yet had to time to test it on my machine. Best regards, Markus > > Good afternoon ! > > > Antoine > > Le 30/07/2012 10:47, Markus Kilås a écrit : >> Hi Antoine, >> >> See answers below. >> >> On 2012-07-28 23:24, Antoine Louiset wrote: >>> Hi Markus, >>> >>> The p12 directory seems to be used to set truststore certificates for >>> JBoss (see >>> http://signserver.org/manual/complete.en.html#4.%20Configure%20web%20server%20keystores) >>> >>> but I think this truststore is just used in the tests of signserver and >>> could be used for the java trust keystore. Jboss and glassfish have >>> their own truststore and keystore, why don't you use them ? >> That is correct. The truststore in the p12 folder is used both by JBoss >> and the tests. So if you are going to run the tests you can put a >> truststore in the p12 folder. I believe the reason for handling it this >> way is that different application servers have different locations for >> the truststore and the tests would not know where to find it. In fact >> where JBoss finds it depends on what is written in the server.xml, so it >> could also be different if SignServer isn't used for deploying it. The >> solution we use, to not depend on different application servers and >> configurations is to decide that it should be placed in the p12 folder >> of SignServer. >> >>> In the signserver_build.properties file, there are several properties >>> which are written for the use of JBoss but we do not know if they are >>> needed for Glassfish : httpsserver.bindaddress.* | database.url | >>> deploy.hostname.node* >> Some are explained in the installation guide, such as "database.url" >> which is said to be used by JBoss and some comments talks about JBoss in >> the sample configuration file. But the documentation is lacking for many >> of the other properties in this aspect. >> >>> What is the aim of deploy.ssh.* properties ? >> I think the idea is to be able to deploy to a remote server by >> transferring the files (signserver.ear etc) over SSH. Not sure if it is >> working though as I can not find any documentation about it. You are >> very welcome to test it out if you want and let us know if it is >> working. If not we might consider either fixing it and adding >> documentation for it or remove it. >> >>> Why j2ee.web-nohttps has to be set to true to launch the tests while >>> https is used in these tests ? >> j2ee.web-nohttps is controlling wither the keystores and truststores >> should be deployed (to JBoss) or not. The tests should not depend on >> this setting so if it says somewhere that it must be set to true I would >> suspect that to be a bug in the documentation. Please report a bug with >> where you seen it in that case. >> >>> The most important thing for me today is tests ! I run them, I resolve >>> the problem about trustanchors. I join the results, I do not understand >>> the errors and the fails, have you ever seen them ? >> From the test report you attached I can see two different failures which >> probably is also the cause of all the errors. >> 1. ExtendedHardCodedCryptoTokenTest testStrongCryptoAvailable >> JCE crypto policy was not installed as the key length was limited >> expected:<2147483647> but was:<64> >> >> This means that you are running the Oracle JDK and have not installed >> JCE crypto policy. See the installation guide. >> >> 2. LimitKeyUsagesTest test01Limit Error Signer 5802 expired at Fri Apr >> 20 16:18:57 CEST 2012 >> Looks like the demo signer certificate used has expired. I will run the >> tests on your continues integration server and see if we have the same >> problem there. They might just have to be renewed. >> >>> How can I send my script to install signserver ? >> If it is less then 40 KB you can just send it to the mailing list, >> otherwise try to upload it somewhere and send the link or send it >> directly to me. >> >>> I take this mail to congratulate you and your team for this project >>> which is really good. >> Thanks to you for reporting the issues you find. >> >> Best regards, >> Markus >> >>> Have a nice weekend. >>> >>> Best regards, >>> >> >> > -- Kind regards, Markus Kilås Security Consultant & Developer PrimeKey Solutions AB Anderstorpsv. 16 171 54 Solna Sweden Phone: +46 70 424 94 85 Skype: markusatskype Email: mar...@pr... www.primekey.se |
|
From: Antoine L. <ant...@yo...> - 2012-07-30 13:28:12
|
Hi Markus, Thanks for your fast answer ! I have just one remark for the JCE installation. I don't find it in the installation guide (I read it quickly). I download JCE policy and it resolves one fail. The problem of the signer 5802 will resolve one fail and one error. So there will be no more fails but I have no idea about the other errors. What do you think about them ? Good afternoon ! Antoine Le 30/07/2012 10:47, Markus Kilås a écrit : > Hi Antoine, > > See answers below. > > On 2012-07-28 23:24, Antoine Louiset wrote: >> Hi Markus, >> >> The p12 directory seems to be used to set truststore certificates for >> JBoss (see >> http://signserver.org/manual/complete.en.html#4.%20Configure%20web%20server%20keystores) >> but I think this truststore is just used in the tests of signserver and >> could be used for the java trust keystore. Jboss and glassfish have >> their own truststore and keystore, why don't you use them ? > That is correct. The truststore in the p12 folder is used both by JBoss > and the tests. So if you are going to run the tests you can put a > truststore in the p12 folder. I believe the reason for handling it this > way is that different application servers have different locations for > the truststore and the tests would not know where to find it. In fact > where JBoss finds it depends on what is written in the server.xml, so it > could also be different if SignServer isn't used for deploying it. The > solution we use, to not depend on different application servers and > configurations is to decide that it should be placed in the p12 folder > of SignServer. > >> In the signserver_build.properties file, there are several properties >> which are written for the use of JBoss but we do not know if they are >> needed for Glassfish : httpsserver.bindaddress.* | database.url | >> deploy.hostname.node* > Some are explained in the installation guide, such as "database.url" > which is said to be used by JBoss and some comments talks about JBoss in > the sample configuration file. But the documentation is lacking for many > of the other properties in this aspect. > >> What is the aim of deploy.ssh.* properties ? > I think the idea is to be able to deploy to a remote server by > transferring the files (signserver.ear etc) over SSH. Not sure if it is > working though as I can not find any documentation about it. You are > very welcome to test it out if you want and let us know if it is > working. If not we might consider either fixing it and adding > documentation for it or remove it. > >> Why j2ee.web-nohttps has to be set to true to launch the tests while >> https is used in these tests ? > j2ee.web-nohttps is controlling wither the keystores and truststores > should be deployed (to JBoss) or not. The tests should not depend on > this setting so if it says somewhere that it must be set to true I would > suspect that to be a bug in the documentation. Please report a bug with > where you seen it in that case. > >> The most important thing for me today is tests ! I run them, I resolve >> the problem about trustanchors. I join the results, I do not understand >> the errors and the fails, have you ever seen them ? > From the test report you attached I can see two different failures which > probably is also the cause of all the errors. > 1. ExtendedHardCodedCryptoTokenTest testStrongCryptoAvailable > JCE crypto policy was not installed as the key length was limited > expected:<2147483647> but was:<64> > > This means that you are running the Oracle JDK and have not installed > JCE crypto policy. See the installation guide. > > 2. LimitKeyUsagesTest test01Limit Error Signer 5802 expired at Fri Apr > 20 16:18:57 CEST 2012 > Looks like the demo signer certificate used has expired. I will run the > tests on your continues integration server and see if we have the same > problem there. They might just have to be renewed. > >> How can I send my script to install signserver ? > If it is less then 40 KB you can just send it to the mailing list, > otherwise try to upload it somewhere and send the link or send it > directly to me. > >> I take this mail to congratulate you and your team for this project >> which is really good. > Thanks to you for reporting the issues you find. > > Best regards, > Markus > >> Have a nice weekend. >> >> Best regards, >> > > -- Antoine Louiset Tél : +33 6 76 66 80 34 Responsable du projet Yousign Mail : ant...@yo... |
|
From: Markus K. <ma...@pr...> - 2012-07-30 08:45:51
|
Hi Antoine, See answers below. On 2012-07-28 23:24, Antoine Louiset wrote: > Hi Markus, > > The p12 directory seems to be used to set truststore certificates for > JBoss (see > http://signserver.org/manual/complete.en.html#4.%20Configure%20web%20server%20keystores) > but I think this truststore is just used in the tests of signserver and > could be used for the java trust keystore. Jboss and glassfish have > their own truststore and keystore, why don't you use them ? That is correct. The truststore in the p12 folder is used both by JBoss and the tests. So if you are going to run the tests you can put a truststore in the p12 folder. I believe the reason for handling it this way is that different application servers have different locations for the truststore and the tests would not know where to find it. In fact where JBoss finds it depends on what is written in the server.xml, so it could also be different if SignServer isn't used for deploying it. The solution we use, to not depend on different application servers and configurations is to decide that it should be placed in the p12 folder of SignServer. > > In the signserver_build.properties file, there are several properties > which are written for the use of JBoss but we do not know if they are > needed for Glassfish : httpsserver.bindaddress.* | database.url | > deploy.hostname.node* Some are explained in the installation guide, such as "database.url" which is said to be used by JBoss and some comments talks about JBoss in the sample configuration file. But the documentation is lacking for many of the other properties in this aspect. > > What is the aim of deploy.ssh.* properties ? I think the idea is to be able to deploy to a remote server by transferring the files (signserver.ear etc) over SSH. Not sure if it is working though as I can not find any documentation about it. You are very welcome to test it out if you want and let us know if it is working. If not we might consider either fixing it and adding documentation for it or remove it. > > Why j2ee.web-nohttps has to be set to true to launch the tests while > https is used in these tests ? j2ee.web-nohttps is controlling wither the keystores and truststores should be deployed (to JBoss) or not. The tests should not depend on this setting so if it says somewhere that it must be set to true I would suspect that to be a bug in the documentation. Please report a bug with where you seen it in that case. > > The most important thing for me today is tests ! I run them, I resolve > the problem about trustanchors. I join the results, I do not understand > the errors and the fails, have you ever seen them ? >From the test report you attached I can see two different failures which probably is also the cause of all the errors. 1. ExtendedHardCodedCryptoTokenTest testStrongCryptoAvailable JCE crypto policy was not installed as the key length was limited expected:<2147483647> but was:<64> This means that you are running the Oracle JDK and have not installed JCE crypto policy. See the installation guide. 2. LimitKeyUsagesTest test01Limit Error Signer 5802 expired at Fri Apr 20 16:18:57 CEST 2012 Looks like the demo signer certificate used has expired. I will run the tests on your continues integration server and see if we have the same problem there. They might just have to be renewed. > > How can I send my script to install signserver ? If it is less then 40 KB you can just send it to the mailing list, otherwise try to upload it somewhere and send the link or send it directly to me. > > I take this mail to congratulate you and your team for this project > which is really good. Thanks to you for reporting the issues you find. Best regards, Markus > > Have a nice weekend. > > Best regards, > -- Kind regards, Markus Kilås Security Consultant & Developer PrimeKey Solutions AB Anderstorpsv. 16 171 54 Solna Sweden Phone: +46 70 424 94 85 Skype: markusatskype Email: mar...@pr... www.primekey.se |
|
From: Antoine L. <ant...@yo...> - 2012-07-28 21:49:39
|
Hi Markus, The p12 directory seems to be used to set truststore certificates for JBoss (see http://signserver.org/manual/complete.en.html#4.%20Configure%20web%20server%20keystores) but I think this truststore is just used in the tests of signserver and could be used for the java trust keystore. Jboss and glassfish have their own truststore and keystore, why don't you use them ? In the signserver_build.properties file, there are several properties which are written for the use of JBoss but we do not know if they are needed for Glassfish : httpsserver.bindaddress.* | database.url | deploy.hostname.node* What is the aim of deploy.ssh.* properties ? Why j2ee.web-nohttps has to be set to true to launch the tests while https is used in these tests ? The most important thing for me today is tests ! I run them, I resolve the problem about trustanchors. I join the results, I do not understand the errors and the fails, have you ever seen them ? How can I send my script to install signserver ? I take this mail to congratulate you and your team for this project which is really good. Have a nice weekend. Best regards, -- Antoine Louiset Responsable du projet Yousign Mail : ant...@yo... |
|
From: Markus K. <ma...@pr...> - 2012-07-27 08:08:23
|
Hi Antoine, (Please include the mailing list address when replying to threads in the list: sig...@li...). See answers below. On 2012-07-27 09:57, Antoine Louiset wrote: > I try to list all the things to do to install signserver in the good > way. I will send to the community a server script which install > signserver in a new linux server. Great, that sounds like a useful script. > > I think there is a problem with enabling a lot of modules to run the > tests, especially module which should not be used in production (for > example clusterclassloader) because we have to launch tests before > sending in production. I think only tests of activated modules should be > launched. Currently the tests are only meant to be run at development time. They are not built to being run in production. One reason is that they might leave data behind in the database. Best regards, Markus > > Best regards, > > Le 27/07/2012 09:41, Markus Kilås a écrit : >> Hi Antoine, >> >> The documentation for developers is lacking a bit... What we have is >> doc/DEVELOP.txt which gives an introduction to testing and refers >> further to the Testing chapter of the manual: >> http://www.signserver.org/manual/complete.en.html#Testing >> >> However, there should also be a note saying that you will have to >> configure the 8442/8443 ports if you are using GlassFish. Also for the >> tests the port number should be taken from the >> signserver_build.properties configuration file but I don't think it is >> like that everywhere yet. >> >> I have registered https://jira.primekey.se/browse/DSS-512 for updating >> the manual. >> >> For the trust anchor error, I think some tests assume there to be a >> truststore (for instance a copy of your cacerts.jks) available as >> p12/truststore.jks with password changeit. Look in the test code and you >> should find some code loading keystores. >> >> >> Best regards, >> Markus >> >> On 2012-07-26 19:34, Antoine Louiset wrote: >>> You were right ! It works with NetBeans 7.1.2 !!! >>> >>> I have one remark for the tests. In many files, you put the number of >>> the port. For example, the address for the WSDL files. When you change >>> the number of ports for the http-listener, you have to change it >>> everywere. By default, glassfish listen to 8181 for https without client >>> authentication (I change it to 8442 to be the same as jboss, it could be >>> interesting to put it in the doc). It will be better to set it once for >>> everywhere. It is just a small improvement which could run the tests >>> without errors faster. >>> >>> However, my error of the trust anchors is always there. >>> [junit] >>> Testcase:testReloadConfiguration(org.signserver.adminws.client.AdminWebServiceTest): >>> >>> Caused an ERROR >>> [junit] Failed to access the WSDL at: >>> https://localhost:8181/signserver/AdminWSService/AdminWS?wsdl. >>> It failed with: >>> [junit] java.lang.RuntimeException: Unexpected error: >>> java.security.InvalidAlgorithmParameterException: the trustAnchors >>> parameter must be non-empty." >>> >>> Is there something to do with cacert or anything else to run tests ? >>> >>> Thanks a lot Markus, >>> >>> Le 25/07/2012 20:35, Markus Kilås a écrit : >>>> Reverting the changes automagically done in */build-impl.xml, >>>> */genfiles.properties, */project.properties and */project.xml and use >>>> NetBeans IDE 7.1.2 should work until the problem is found and fixed. >> >> > -- Kind regards, Markus Kilås Security Consultant & Developer PrimeKey Solutions AB Anderstorpsv. 16 171 54 Solna Sweden Phone: +46 70 424 94 85 Skype: markusatskype Email: mar...@pr... www.primekey.se |
|
From: Markus K. <ma...@pr...> - 2012-07-27 07:40:23
|
Hi Antoine, The documentation for developers is lacking a bit... What we have is doc/DEVELOP.txt which gives an introduction to testing and refers further to the Testing chapter of the manual: http://www.signserver.org/manual/complete.en.html#Testing However, there should also be a note saying that you will have to configure the 8442/8443 ports if you are using GlassFish. Also for the tests the port number should be taken from the signserver_build.properties configuration file but I don't think it is like that everywhere yet. I have registered https://jira.primekey.se/browse/DSS-512 for updating the manual. For the trust anchor error, I think some tests assume there to be a truststore (for instance a copy of your cacerts.jks) available as p12/truststore.jks with password changeit. Look in the test code and you should find some code loading keystores. Best regards, Markus On 2012-07-26 19:34, Antoine Louiset wrote: > You were right ! It works with NetBeans 7.1.2 !!! > > I have one remark for the tests. In many files, you put the number of > the port. For example, the address for the WSDL files. When you change > the number of ports for the http-listener, you have to change it > everywere. By default, glassfish listen to 8181 for https without client > authentication (I change it to 8442 to be the same as jboss, it could be > interesting to put it in the doc). It will be better to set it once for > everywhere. It is just a small improvement which could run the tests > without errors faster. > > However, my error of the trust anchors is always there. > [junit] > Testcase:testReloadConfiguration(org.signserver.adminws.client.AdminWebServiceTest): > Caused an ERROR > [junit] Failed to access the WSDL at: > https://localhost:8181/signserver/AdminWSService/AdminWS?wsdl. > It failed with: > [junit] java.lang.RuntimeException: Unexpected error: > java.security.InvalidAlgorithmParameterException: the trustAnchors > parameter must be non-empty." > > Is there something to do with cacert or anything else to run tests ? > > Thanks a lot Markus, > > Le 25/07/2012 20:35, Markus Kilås a écrit : >> Reverting the changes automagically done in */build-impl.xml, >> */genfiles.properties, */project.properties and */project.xml and use >> NetBeans IDE 7.1.2 should work until the problem is found and fixed. > -- Kind regards, Markus Kilås Security Consultant & Developer PrimeKey Solutions AB Anderstorpsv. 16 171 54 Solna Sweden Phone: +46 70 424 94 85 Skype: markusatskype Email: mar...@pr... www.primekey.se |
8 messages has been excluded from this view by a project administrator.
