geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From viola lu <viola...@gmail.com>
Subject Re: Keystore files filter problem under var/security/keystores
Date Thu, 13 Oct 2011 02:58:51 GMT
On Thu, Oct 13, 2011 at 10:02 AM, Ivan <xhhsld@gmail.com> wrote:

> Add a filter option should be fine, and it should be also allowed no
> suffix, IIRC Geronimo's own store files are of no suffix.
>

 Right, no suffix should be included.


> While I am thinking why those other files are there, does those csr files
> are generated by the console and store there by default ?If does, we may
> just need to update those logic.


    End-user is using jdk keytool to generate csr and certificates, not
console. Our console CA portlet generates CSR and cerificates to its ca
specific folder, not keystore folder, so no need to change this logic.


> Also, it looks to me that the user will not create an empty file there
> manually, that action makes no sense.


  Some types of keystore files permits empty file. So we just need to check
its type whether in empty allowed keystore file.


>
> 2011/10/13 Forrest Xia <forrestxm@gmail.com>
>
>> Make a doc, and tell user not putting non-keystore files in that folder,
>> might be an option :)
>>
>> Forrest
>>
>>
>> On Wed, Oct 12, 2011 at 6:16 PM, viola lu <viola.lu@gmail.com> wrote:
>>
>>> Hi, Dev:
>>>
>>>  Currently in geronimo 2.1.*, if i run keytool in jdk to generate csr or
>>> other non-keystore files under var/security/keystores, geronimo server will
>>> persist them in j2ee-security module when i access keystore porlet in admin
>>> console, which scans all files under this folder and instance
>>> FileKeystoreInstance GBean no matter what type of file.
>>> If so, even user create an empty file of any type, it will be written to
>>> config.xml. We have to filter files, only keystore files should be under
>>> that folder.
>>>
>>> I plan to filter files under var/security/keystore through file name
>>> postfix, for example: *, *.jks, *.pcks, but is there other way to valid
>>> content of keystore? From keystore api in jdk, it must provide a password
>>> before load and access it, which we don't know except the user who generate
>>> it.
>>>
>>> Any suggestion?
>>>
>>> --
>>> viola
>>>
>>> Apache Geronimo
>>>
>>>
>>
>
>
> --
> Ivan
>



-- 
viola

Apache Geronimo

Mime
View raw message