perfSONAR User Q&A and Other Discussion

[Andrew Lake <>]

Actually I had no luck with that approach. I tried that first and still got 
the error. I found posts where other people also complained this did not 
work. It was many months ago but I was pretty positive at the time I was 
nuking the right certificate. It was likely with an older version of Firefox, 
so it may work now.

On Nov 11, 2010, at 11:06 AM, Tom Throckmorton wrote:

> On 11/11/10 11:01 AM, Andrew Lake wrote:
>> Hi,
>> 
>> I ran into this problem with Firefox awhile back after upgrading a host 
>> and was able to fix it on my client machine. Do you run Firefox on a Mac? 
>> If so I was able to get rid of this error by running the following in 
>> Terminal:
>> 
>> rm ~/Library/Application\ 
>> Support/Firefox/Profiles/u0wszv82.default/cert8.db
>> 
>> After much googling that was the only way I found to clear out the old 
>> certificate from Firefox. After that I restarted Firefox and the problem 
>> went away. 
> 
> Deleting the cert8.db isn't necessary.  Certs that Firefox knows of can
> be managed directly, under Preferences, Advanced, Encryption, View
> Certificates, then look at the certs listed under 'Servers'. From there
> the cert can be deleted as needed.
> 
> I use a _lot_ of self-signed certs for testing, and nuking my cert.db
> and having to re-accept all of them would be....painful.
> 
> -tt
> 
> 
>> 
>> Andy
>> 
>> 
>> On Nov 11, 2010, at 10:39 AM, jim warner wrote:
>> 
>>> I tried this; it had no effect. And when I click on the broken padlock 
>>> (using chrome as the browser), the date on the cert is the date I 
>>> switched this computer from 3.1.3 to 3.2.  So it DID generate a new 
>>> certificate and that it did this without changing the serial number 
>>> probably IS the problem. And the two lines you suggested are generating a 
>>> new certificate but -- somehow -- not putting into place where it will 
>>> get used.  Here are the some of the lines that appear from the 
>>> 'generate_cert' script:
>>> 
>>>>       /usr/bin/openssl req -utf8 -new -key 
>>>> /etc/pki/tls/private/localhost.key -x509 -days 365 -out 
>>>> >/etc/pki/tls/certs/localhost.crt -set_serial 0
>>>> You are about to be asked to enter information that will be incorporated
>>>> into your certificate request.
>>>> What you are about to enter is what is called a Distinguished Name or a 
>>>> DN.
>>>> There are quite a few fields but you can leave some blank
>>>> For some fields there will be a default value,
>>>> If you enter '.', the field will be left blank.
>>> It appears that the serial number is hard coded in the script.
>>> 
>>> 
>>> On 11/10/2010 12:19 PM, Jason Zurawski wrote:
>>>> Hi Jim;
>>>> 
>>>> On 11/10/10 12:21 PM, jim warner wrote:
>>>>> When I attempt to authenticate through the browser to admin the toolkit,
>>>>> Firefox is giving me an error message:
>>>>> 
>>>>>> Your certificate contains the same serial number as another
>>>>>> certificate issued by the certificate authority. Please get a new
>>>>>> certificate containing a unique serial number.
>>>>>> 
>>>>>> (Error code: sec_error_reused_issuer_and_serial)
>>>>> We are running two instances of Perfsonar on separate computers.
>>>>> Actually we might
>>>>> have more than that. Could that have something to do with this message?
>>>>> These
>>>>> are liveCDs. I don't think I saw anything in the release notes about
>>>>> this. This is not
>>>>> an error that FireFox will allow me to click through. This is release 
>>>>> 3.2.
>>>> Try this:
>>>> 
>>>> 1) Remove '/etc/pki/tls/private/localhost.key'
>>>> 2) Run 'sudo /etc/init.d/generate_cert_init_script start'
>>>> 
>>>> When upgrading to 3.2 it should have re-generated this script 
>>>> automatically, but these steps will force that step again.
>>>> 
>>>> Thanks;
>>>> 
>>>> -jason
>>>> 
>> 
> 
> 
> -- 
> Tom Throckmorton
> MCNC
> 919.248.1448
> 
> "Connecting North Carolina's future today"