Hi Tomas,
Yes, I was picking the keystore from a different location by defining its
path within server.xml. I had overseen it second time round!
So I thank you once again for your time! And well done for the prompt help!
I really do appreciate it!
Regards,
Chris
cporter wrote:
>
> Hmmm ...
>
> I'll have a look in there Tomas!
>
>
> Tomas Gustavsson wrote:
>>
>> You don't have to old JBoss directory still around so it somehow uses
>> those files?
>>
>
> It is still there, but on another volume (i.e. E:\)... So I don't think it
> should be affecting the new installation... I will make sure that no
> conflicts arise though (through renaming).
>
> I thank you Tomas for your help. I'll keep you posted!
>
> Chris
>
>
> Tomas Gustavsson wrote:
>>
>>
>> You can look in JBoss where it picks up the tomcat/keystore.jks file
>> actually. In the file
>> JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/server.xml (for
>> JBoss 4.0.5, in JBoss 4.2.0 the path is jboss-web.deployes instead).
>> In server.xml the keystore is named.
>>
>> You don't have to old JBoss directory still around so it somehow uses
>> those files?
>>
>> Cheers,
>> Tomas
>>
>> cporter skrev:
>>> Hi Tomas,
>>>
>>> Yes, I have complete access to Admin GUI, but with warnings from the
>>> browser
>>> side (not EJBCA).
>>>
>>>
>>> Tomas Gustavsson-4 wrote:
>>>> ...tomcat.jks should be copied to
>>>> $JBOSS_HOME/server/default/conf/keystore/keystore.jks...
>>>>
>>>
>>> ... hmmm .. in there I've got the tomcat.jks (not keystore.jks), which
>>> after
>>> deployment (ant deploy) the timestamp was still the old one. Thus, I've
>>> overwritten it with the new tomcat.jks (Not keystore.jks though!). I
>>> made
>>> sure that all JKSs are the latest version (i.e. 7th August). But
>>> somehow, it
>>> still gave me the old server certificate (for the Admin GUI).
>>>
>>> This issue is not actually affecting newly generated end-entity
>>> certificates
>>> (as they have a valid cert. chain) with the root certificate being the
>>> newly
>>> generated server certificate (with the correct serial number). Somehow,
>>> the
>>> admin GUI is still making use of a "ghost" certificate! :-/
>>>
>>> I will try renaming the tomcat.jks to keystore.jks into
>>> $JBOSS_HOME/server/default/conf/keystore/.... I assumed that
>>> installation
>>> and deployment would do that on its own.
>>>
>>>
>>> Tomas Gustavsson-4 wrote:
>>>> 1. Is the problem is that you can still access the Admin GUI with an
>>>> old
>>>> superadmin.p12 imported to IE?
>>>> 2. Is the error message generated by the webbrowser or EJBCA?
>>>> 3. Did you repopulate the database with old content or was it populated
>>>> during the install?
>>>>
>>>
>>> 1. The superadmin.p12 is actually is the new certificate... in fact the
>>> client OSs were re-installed, and thus there were no previous p12s
>>> imported.
>>> (Only the new Superadmin and User certificates were imported).
>>>
>>> 2. Error is generated by the webbrowser.
>>>
>>> 3. No, the DB was populated afresh during install (in fact I even had to
>>> re-install Postgres 8.0).
>>> (Not many users are active on the PKI for the time being, so it was no
>>> big
>>> deal to re-issue certain certificates).
>>>
>>> I will try to put the keystore.jks (rather than tomcat.jks) in the
>>> Server
>>> folders. And will get back to you ...
>>>
>>> I thank you for your prompt reply Tomas.
>>>
>>> I guess that there is something minor involved here ... I am sure.
>>>
>>> Regards,
>>>
>>> Chris
>>>
>>>
>>>
>>> Tomas Gustavsson-4 wrote:
>>>> Hi Chris,
>>>>
>>>> If I understood everything correctly you are able to access the Admin
>>>> GUI with the newly generated superadmin.p12 in IE (but with warnings).
>>>>
>>>> You are probably right when you assume that it's the
>>>> serverside-certificate not working. tomcat.jks should be copied to
>>>> $JBOSS_HOME/server/default/conf/keystore/keystore.jks, but this should
>>>> have been done automatically during the install. JBoss needs to be
>>>> restarted to pick this up though. You might want to start by
>>>> doublechecking the date if the keystore to see if this was overwritten
>>>> during the install. Maybe you did some hardening last time?
>>>>
>>>> Just somewhere to start.. hope this helps.
>>>>
>>>> And if it doesn't:
>>>> 1. Is the problem is that you can still access the Admin GUI with an
>>>> old
>>>> superadmin.p12 imported to IE?
>>>> 2. Is the error message generated by the webbrowser or EJBCA?
>>>> 3. Did you repopulate the database with old content or was it populated
>>>> during the install?
>>>>
>>>>
>>>> /Johan
>>>>
>>>>
>>>> cporter skrev:
>>>>> Hi everyone...
>>>>>
>>>>> Due to an upgrade on the server, certain EJBCA (3.4.1) and Jboss
>>>>> (4.0.4.GA)
>>>>> settings had to be re-set to reflect the new infrastructure...
>>>>>
>>>>> This was carried out and EJBCA was up and running in no time.
>>>>> Obviously,
>>>>> new
>>>>> root certificates had to be generated, together with the corresponding
>>>>> superadmin certificate. These were also installed on the client
>>>>> machines
>>>>> which make use of the server (internally), which certification path
>>>>> was
>>>>> also
>>>>> verified.
>>>>>
>>>>> There is only one problem though.... whenever I log into the
>>>>> administration
>>>>> section, I am prompted to choose the admin certificate (and the
>>>>> superadmin
>>>>> is chosen); but somehow, the superadmin's signing certificate, has a
>>>>> different serial number than the one which the
>>>>> https://servername:8443/ejbca/adminweb uses.
>>>>>
>>>>> This is obviously causing an untrusted certificate message, although I
>>>>> still
>>>>> can make use of the Administration facilities through IE (with warning
>>>>> messages).
>>>>>
>>>>> The keystore (tomcat.jks) generated within the p12 directory was also
>>>>> copied
>>>>> onto jboss's default server deploy\keystore folder. But somehow, it is
>>>>> still
>>>>> making use of the certificate generated in the previous installation
>>>>> (March
>>>>> 07) whenever I request an https resource.
>>>>>
>>>>> I carrried out an ant Clean/Bootstrap/Install/Deploy (or copy) in
>>>>> order
>>>>> to
>>>>> re-deploy everything (including Postgres table population), but
>>>>> somehow
>>>>> there is some residue which is causing this problem.
>>>>>
>>>>> Can you please give me some hints on what might be causing this
>>>>> problem?
>>>>>
>>>>> I thank you beforehand for your time...
>>>>>
>>>>> Chris Porter
>>>>>
>>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Splunk Inc.
>>>> Still grepping through log files to find problems? Stop.
>>>> Now Search log events and configuration files using AJAX and a browser.
>>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>>> _______________________________________________
>>>> Ejbca-develop mailing list
>>>> Ejbca-develop@...
>>>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>>>
>>>>
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejbca-develop@...
>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Root-Certificate-Residues---Mismatched-cert.-SN-tf4234826.html#a12058040
Sent from the EjbCA - Dev mailing list archive at Nabble.com.
|