Closed Bug 578499 Opened 14 years ago Closed 13 years ago

Enable Izenpe.com root certificate for EV in PSM

Categories

(Core :: Security: PSM, enhancement)

Product:
Core
Component:
Security: PSM
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: kathleen.a.wilson, Unassigned)

References

Details

(Whiteboard: [waiting-for-ca])

Attachments

(1 file)

Minefield report
30.90 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details 
Per bug 361957 the request from Izenpe has been approved to enable
its "Izenpe.com" root certificate for EV use. Please make the corresponding changes to PSM.

The relevant information is as follows.

Friendly name: Izenpe.com

SHA1 Fingerprint: 2F:78:3D:25:52:18:A7:4A:65:39:71:B5:2C:A2:9C:45:15:6F:E9:19

EV policy OID: 1.3.6.1.4.1.14777.6.1.1

Test URL: https://www.it-txartela.net
Iñigo, Please confirm that the above information is correct.
Hi Kathleen,

yes, it´s correct.

BTW, in the meanwhile we have created a new EV policy ID por the so called "site certificate" according to the spanish legislation. This new EV policy OID is: 1.3.6.1.4.1.14777.6.1.2

Can you include this also? Do we need to create a new request bug? Both are issued from the same issuing CA and the same root.

Regards
Kathleen,

I forgot to include a test site: https://www.balmaseda.net

Regards
>> BTW, in the meanwhile we have created a new EV policy ID por the so 
>> called "site certificate" according to the spanish legislation. 
>> This new EV policy OID is: 1.3.6.1.4.1.14777.6.1.2
>>
>> Can you include this also? 
>> Both are issued from the same issuing CA and the same root.

So the request is for there to be two EV Policy OIDs associated with this root.

EV policy OID: 1.3.6.1.4.1.14777.6.1.1
EV policy OID: 1.3.6.1.4.1.14777.6.1.2

We haven't had two EV Policy OIDs for a root before, but it has also been requested in bug #562399.

We'll have to see what happens during testing.

Note that this bug is dependent on bug 578491 because the root certificates need to be included in NSS before they can be enabled for EV in the PSM. Therefore, this particular bug won't get worked on until after bug 578491 has been completed and included in a release of Firefox.
Sorry,

the website to test is: www.testsedeconev.es

Regards
Depends on: 582579
I'm testing a build that includes your root, and enables roots for EV, for both OIDs you have specified.

While I get a general root verification success, I see failure in EV testing.

For https://www.it-txartela.net/
I get verified SSL, but EV fails.
Whenever I saw this in the past, it was due to an incorrect OCSP server setup.

I see the same result for https://www.testsedeconev.es/

For https://www.balmaseda.net/
I see an error message:
  An error occurred during a connection to www.balmaseda.net.
  Invalid OCSP signing certificate in OCSP response.
  (Error code: sec_error_ocsp_invalid_signing_cert)

Iñigo, can you please verify that your OCSP server works correctly and your OCSP server certificate follows the specifications?


FYI, I made sure the problems is not related to "enabling two EV OIDs".
As an additional test, I enabled only the first OID, and still saw the EV failure and the OCSP server error message.
Despite the failures seen with your OCSP server, I've provided a test build, which includes your root, and which enables your root for EV, so you can test yourself.

Current test builds (Mozilla experimental) for various platforms can be found
at
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/kaie@kuix.de-92eacf382419/

Please note the builds at above location will be automatically deleted after
two weeks, so please make copies if you need them.

Enabling your root for EV will be postponed until we see a positive test result.
(In reply to comment #6)
> While I get a general root verification success, I see failure in EV testing.
> 
> For https://www.it-txartela.net/
> I get verified SSL, but EV fails.

It fails on OCSP validation of the intermediate CA (the one just above www.it-txartela.net).

The OCSP responder declared at URL http://ocsp.izenpe.com:8097 (the one indicated in www.it-txartela.com's certificate) is signed by the "CA de Certificados SSL EV" certificate, the same that issued the www.it-txartela.com's one. This "CA de Certificados SSL EV" certificate is signed by the Izenpe.com root.

When Mozilla wants to OCSP-validate "CA de Certificados SSL EV" certificate, he sends the request to http://ocsp.izenpe.com:8094, and the OCSP responder is signed by another CA (let's call it "CA Tecnica", its real name is much longer), which itself is signed by a CA called "Izenpe.com" (again, with much more information), but is different than the Izenpe.com above. Nothing can link "CA Tecnica" to the "Izenpe.com" root (and this "CA Tecnica" doesn't have an OCSP responder).

Beside that, 2 CRLs (in fact, ARLs issued by "Izenpe.com" root and the second "Izenpe.com" CA (the one we don't have) have a critical IssuingDistributionPoint extension, even if it's not necessary (this extension doesn't restrict the range of the CRL).

Checking this by hand is a mess :(
(In reply to comment #8)
> (In reply to comment #6)
> > While I get a general root verification success, I see failure in EV testing.
> > 
> > For https://www.it-txartela.net/
> > I get verified SSL, but EV fails.

> It fails on OCSP validation of the intermediate CA (the one just above
> www.it-txartela.net).

Same reason for the 2 other test websites.

> The OCSP responder declared at URL http://ocsp.izenpe.com:8097 (the one
> indicated in www.it-txartela.com's certificate) is signed by the "CA de
> Certificados SSL EV" certificate, the same that issued the
> www.it-txartela.com's one. This "CA de Certificados SSL EV" certificate is
> signed by the Izenpe.com root

The web-site sends another root certificate, the SHA1 one, which is not the "Old Root" found in bug 361957.

> When Mozilla wants to OCSP-validate "CA de Certificados SSL EV" certificate, he
> sends the request to http://ocsp.izenpe.com:8094, and the OCSP responder is
> signed by another CA (let's call it "CA Tecnica", its real name is much
> longer), which itself is signed by a CA called "Izenpe.com" (again, with much
> more information), but is different than the Izenpe.com above. Nothing can link
> "CA Tecnica" to the "Izenpe.com" root (and this "CA Tecnica" doesn't have an
> OCSP responder).

In fact, this other "Izenpe.com" CA is precisely the "Old Root" found in bug 361957. It's a completely different CA.

> Beside that, 2 CRLs (in fact, ARLs issued by "Izenpe.com" root and the second
> "Izenpe.com" CA (the one we don't have) have a critical
> IssuingDistributionPoint extension, even if it's not necessary (this extension
> doesn't restrict the range of the CRL).

That was already noticed and subject to correction here: https://bugzilla.mozilla.org/show_bug.cgi?id=361957#c61

Since OCSP can't work, EV can't work either.

In comment 65, thoses CRLs seem to have this extension either declared as non critical, or completely removed. Why did this change back to the old situation?
The Izenpe representative is currently on holiday. I am communicating with him via email, but he cannot access bugzilla at this time.

Erwann, Thank you for your thorough evaluation of this issue.

In https://bugzilla.mozilla.org/show_bug.cgi?id=361957#c100 we had realized that Izenpe's OCSP responder using port 8094 uses a VA that was not certified by the same CA that issues the SSL cert to the web site, so the OCSP validation fails in Firefox.

So Izenpe created a new OCSP responder using port 8097 which works without error in Firefox.

As you noted in Comment #8, the end-entity cert has AIA OCSP URI http://ocsp.izenpe.com:8097, but the intermediate EV CA has AIA OCSP URI http://ocsp.izenpe.com:8094 (the old OCSP responder).

Therefore, before EV will work for this root, Izenpe will need to create a new intermediate CA for EV, with a new AIA OCSP URI.

Additionally, Izenpe was planning to change their new OCSP responder from port 8097 to port 80, as per feedback during the public discussion.

So, before this root can be EV-enabled, Izenpe will need to complete two action items:
1) Update their OCSP responder to port 80.
2) Issue a new intermediate CA for EV which has the new AIA OCSP URI.

QUESTION TO ALL: Do these action items also need to be completed before the root can be included in NSS? (It seems to me that this issue is specific to EV-enablement.)

Thanks,
Kathleen
(In reply to comment #10)
> 
> QUESTION TO ALL: Do these action items also need to be completed before the
> root can be included in NSS? (It seems to me that this issue is specific to
> EV-enablement.)

During my testing I ran into a popup error about a broken OCSP server.

I think, until the OCSP server infrastructure gets resolved and the bad intermediate cert gets wiped out everywhere, end users could still run into this error popup?

If my understanding is correct, I'd propose to delay shipping the root until we're sure users won't get those OCSP error messages.
(In reply to comment #11)
> 
> I think, until the OCSP server infrastructure gets resolved and the bad
> intermediate cert gets wiped out everywhere, end users could still run into
> this error popup?

... because we perform OCSP verifications even when not doing EV checks.
(In reply to comment #10)
> QUESTION TO ALL: Do these action items also need to be completed before the
> root can be included in NSS? (It seems to me that this issue is specific to
> EV-enablement.)

This issue is not specific to EV-enablement, since a test website's certificate (www.balmaseda.net) has the :8094 OCSP responder, and this is the reason of the error message by Kai in his #c6 message. This message isn't an EV error, it's an SSL error.

I don't know why Firefox cries for this certificate and not the others, though. I also don't know how Firefox can validate the 2 other websites, since the OCSP reply for the intermediate CA is invalid, and the CRL can't be used (due to the unnecessary critical extension).

The question could be transformed: should Firefox be taken responsible for SSL errors not under its control?
In bug 361957, Izenpe.com's representatives talk about "bad user experience", and about users banning Firefox usage (#c107). Bad user experience will persist, because of these errors, and these won't be Mozilla's fault.

My answer would be a "no". OCSP responders who don't follow an 11 years old RFC, CAs that produce sequential serial numbers in certificates with a declining hash function, all this shouldn't be trusted. (random serial numbers will be the only defense against false certificates when SHA1 collisions will appear, as it is the only defense against MD5 collisions).

All this is about trust.
The SSL cert for https://www.balmaseda.net was mistakenly issued with an AIA OCSP URI pointing to port 8094 (the old OCSP responder). That is why Iñigo posted the update in Comment 5.

The correct test websites are as follows.

EV policy OID: 1.3.6.1.4.1.14777.6.1.1
Test URL: https://www.it-txartela.net

EV policy OID: 1.3.6.1.4.1.14777.6.1.2
Test URL: https://www.testsedeconev.es

However, I think there are two problems which merit postponing this request.
1) The new port, 8097, doesn't appear to be part of the standard cert issuance process yet, which is why I think the mistake was made.
2) The intermediate CA points to the old OCSP Responder, which doesn't work within Firefox.

I have also recommended postponing inclusion in NSS:
https://bugzilla.mozilla.org/show_bug.cgi?id=578491#c7
No longer depends on: 582579
The issues noted in Comment 14 have been addressed, as per
https://bugzilla.mozilla.org/show_bug.cgi?id=578491#c8

The new test websites are 
EV (OID 1.3.6.1.4.1.14777.6.1.1)  https://servicios.izenpe.com
Sede EV (OID 1.3.6.1.4.1.14777.6.1.2) https://servicios1.izenpe.com
Depends on: 614852
I get successful SSL connections to your test sites from comment 15,
but I don't get EV yet.

In the past when testing new roots for EV, this commonly meant there is a problem with the OCSP server.
Are you sure the OCSP server is working?
I investigated why the OCSP responses from ocsp.izenpe.com are not accepted by NSS.

NSS gives us error code SEC_ERROR_OCSP_UNAUTHORIZED_RESPONSE.

NSS comments say:
 * There are three ways to be authorized.  In the order in which we check,
 * using the terms used in the OCSP spec, the signer must be one of:
 *  1.  A "trusted responder" -- it matches a local configuration
 *      of OCSP signing authority for the certificate in question.
 *  2.  The CA who issued the certificate in question.
 *  3.  A "CA designated responder", aka an "authorized responder" -- it
 *      must be represented by a special cert issued by the CA who issued
 *      the certificate in question.

The signing cert used by your OCSP server has the designated responder flag set.

    /*
     * The signer is a designated responder.  Its issuer must match
     * the issuer of the cert being checked.
     */

This test fails.


signer cert (used by ocsp server):
subject: CN=ocsp.izenpe.com,O=IZENPE S.A.,C=ES
issuer:  CN=CA de Certificados SSL EV,OU=BZ Ziurtagiri publikoa - Certificado publico EV,O=IZENPE S.A.,C=ES


I can see that NSS asks the OCSP about status for that issuer.

subject: CN=CA de Certificados SSL EV,OU=BZ Ziurtagiri publikoa - Certificado publico EV,O=IZENPE S.A.,C=ES
issuer:  CN=Izenpe.com,O=IZENPE S.A.,C=ES


And the test for correctness of the OCSP response signature fais, because the above rule is not followed.
Kai, Thank you for investigating this.  I'd like to ask a couple questions
of clarification.

1. It sounds like you're saying that the OCSP check that fails is not a check
on the server cert, but rather on some issuer cert.  I cannot tell if it is 
the issuer of the server cert or the issuer of the OCSP responder cert.  
(They should be the same issuer, but I cannot tell from your comments if that 
is true or not.)

2. Which of the two URLs in comment 15 were you checking (or, if neither of those, what URL were you checking) when you experienced this failure?
I made a new testbuild, now it includes the patch to enable roots for EV.

http://hg.mozilla.org/try/pushloghtml?changeset=c73f0117a36e
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/kaie@kuix.de-c73f0117a36e/

I've learned that tryserver builds are automatically deleted quickly, after 4 days.
I've mirrored the most important files here:
http://kuix.de/mozilla/tryserver-roots-20101125/
(In reply to comment #18)
> 
> 1. It sounds like you're saying that the OCSP check that fails is not a check
> on the server cert, 

correct


> but rather on some issuer cert.

correct.

The issuer cert I talk about is:

subject: CN=CA de Certificados SSL EV,OU=BZ Ziurtagiri publikoa - Certificado
publico EV,O=IZENPE S.A.,C=ES
issuer:  CN=Izenpe.com,O=IZENPE S.A.,C=ES


This intermediate cert issued *both* the
- ocsp server cert
- the web server cert


NSS attempts to perform an OCSP request for the intermediate.

    /*
     * The signer is a designated responder.  Its issuer must match
     * the issuer of the cert being checked.
     */

The cert being checked is the intermediate.
The issuer of the cert being checked is the top root.

The OCSP signer is a designated responder.
The issuer of the signer is the intermediate.

The issuers are different.
NSS reports a failure.


> I cannot tell if it is 
> the issuer of the server cert or the issuer of the OCSP responder cert.  

Both.


> (They should be the same issuer, but I cannot tell from your comments if that 
> is true or not.)

The issuer of the server cert and the OCSP responder cert are the same.

But the issuer of the intermediate cert and the OCSP responder are different.


> 2. Which of the two URLs in comment 15 were you checking (or, if neither of
> those, what URL were you checking) when you experienced this failure?

https://servicios.izenpe.com/
I did some verifications, with other tools (OpenSSL in fact), and it also fails on the same intermediate cert.

(In reply to comment #20)
> The issuer cert I talk about is:
> 
> subject: CN=CA de Certificados SSL EV,OU=BZ Ziurtagiri publikoa - Certificado
> publico EV,O=IZENPE S.A.,C=ES
> issuer:  CN=Izenpe.com,O=IZENPE S.A.,C=ES
> 
> This intermediate cert issued *both* the
> - ocsp server cert
> - the web server cert
> 
> NSS attempts to perform an OCSP request for the intermediate.
> 
>     /*
>      * The signer is a designated responder.  Its issuer must match
>      * the issuer of the cert being checked.
>      */
> 
> The cert being checked is the intermediate.
> The issuer of the cert being checked is the top root.
> 
> The OCSP signer is a designated responder.
> The issuer of the signer is the intermediate.
> 
> The issuers are different.
> NSS reports a failure.

Nice shot. I was searching somewhere else, OpenSSL still tells me "root ca not trusted".

I can also add that servicios.izenpe.com sends a root certificate which is different than the one declared. And the intermediate certificate sent along the SSL connection is not the same as the one sent in the OCSP reply (sha1/sha256).

Strange.
Explanation:

We are now waiting for the CA, Izenpe.com, to ensure correctness of their OCSP server.

You are expected to configure your OCSP server with a certificate according to the SSL/OCSP specifications.
Dear Izenpe.com, sorry, but I conclude you are not yet ready for EV.

We are changing the process for future CA-EV requests, and you will be the first one who is being affected by this new process.

In short, we are expecting that a CA has tested their own infrastructure, and has seen positive test results, prior to requesting EV in Firefox.


The new EV-testing procedures are described here:
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version


(Your life is simpler than described on that page, because you already received a test build that enables your root, you don't need to deal with that special test_ev_roots.txt file and not with environment variables.)


What does this mean for this bug request?
I'm setting the target milestone to "future".

Izenpe.com now has the responsibility to investigate their own infrastructure.

Once you have tested that your infrastructure works correctly (you do see green EV identity bar with a test build), you should report your success in this bug.

Thanks.
Whiteboard: [waiting-for-ca]
Target Milestone: --- → Future
No longer depends on: 614852
Hi there,

First of all I´m sorry for the delay in the response due to internal “problems” (flights, sickness and so on) and couldn´t reply to some of your comments. 
Second, I´m very sad of reading that Kai, because honestly, I think we don´t deserve.
I´d like to summarize the situation and then the conclusions.

Summary

1.- We have a VA that responds for all the issuing CAs. This VA is signed by a technical CA that it´s only for that purpose. This configuration is very common and has no issues with any other software provider
2.- According to the interpretation of the RFC 2560 from Mozilla, that we didn´t share, we created a new VA exclusively for the CA that issues the EV and thru port 80. So, when this was done, it was tested by Mozilla and everything seemed ok. Some test builds were created and sent to us for checking and the results were correct
3.- Then a new requirement came to the show, nothing that we were aware of, and I read that we can´t be included because the requirements have changed

Conclusions:
-	We don´t meet this new NSS requirement. On the other hand I don´t see a big issue on this (personally I don´t think this is so “important” for not being EV on Firefox and I´d like you to recap) but from now we´re working on fixing it. The idea is to have a multiCA VA similar to the initial one but instead of signed by just the technical CA, it´s going to be signed by all the issuing CAs. Hopefully with this change we´ll meet all your requirements, but it´s not an easy change and it will take time. But
o	We´re dealing with you since 2006. Since then, you´ve changed the requirements
o	We were accepting your new requirements, but not sharing some of them, in order to get included finally
o	Again, you´ve added new ones and we´re always the first one to be affected. This is not fair.
-	I´d like to know what this NSS library does or according to what standard we should change our infrastructure

Answers to some questions
-	Our root CA and subordinate CAs are signed with SHA1 and SHA256 all of them, and I applied for including “both” roots but it was suggested (like the other browsers) to include only the newest, the SHA256 signed. By default, the issuing CAs use the SHA1, just in case waiting for a broader use of the SHA256, but this is not an issue nor a problem or mistake. It could be strange as Erwann says but it´s what has been suggested.

Finally, I´d like to know if this affects only to the EV green bar and the root is included in the Firefox or is it affecting both situations?

And, on the end, I can´t believe this situation in general. More than 4 years for this, no problems with the other browsers, being certified in ISO, ETSI and Webtrust, plus some government auditing criteria as we are a Government CA, being the only CA with 2 EV OIDs and recognized for being one of the most secure and securized one (root CA and issuing CAs with 4K length and SHA1 and SHA2 signed) and so on. Unbelievably

Regards
Iñigo,


> 1.- We have a VA that responds for all the issuing CAs. This VA is signed by a
> technical CA that it´s only for that purpose. This configuration is very common
> and has no issues with any other software provider


Other CAs use designated OCSP responder servers, too, and they work fine with our verification requirements.


> 2.- According to the interpretation of the RFC 2560 from Mozilla, that we
> didn´t share, we created a new VA exclusively for the CA that issues the EV and
> thru port 80. So, when this was done, it was tested by Mozilla and everything
> seemed ok. Some test builds were created and sent to us for checking and the
> results were correct


When not using EV, we only check the server cert.
When you talk about "previous checks", these were "initial checks".

Now, when we tried to enable EV, this enables testing of the whole certificate chain. This now includes OCSP testing of your intermediate certificates.


> 3.- Then a new requirement came to the show, nothing that we were aware of, and


This is not a new requirement. It's a failure that isn't seen until testing EV.


> Conclusions:

the problem is simply, it doesn't work.
The same code that works for all other CAs doesn't work with your CA.


> I read that we can´t be included because the requirements have changed


The "requirements for EV" have "not changed".

The only thing hat has changed: We're making it clear that, now, it's your turn, and you have to:
- either analyze your infrastructure more, in particular, verify that you use a correct signer certificate for your OCSP responder
- or explain to us, by citing RFCs, why you believe your OCSP server certificate is correct.
Hi Iñigo,

(In reply to comment #24)
> Summary
> 
> 1.- We have a VA that responds for all the issuing CAs. This VA is signed by a
> technical CA that it´s only for that purpose. This configuration is very common
> and has no issues with any other software provider

No. This is not a "common" configuration (I can only see a justification for it in a corporate environment, certainly not in the wild). And in fact, it has problems with other software validators (web browsers), but those problems are hidden because finally, the CRL is downloaded to validate the certificate.
On MSCAPI platform (IE, Chrome, Safari), OCSP is tested first, with a fallback to CRL.
On MacOSX (Safari), OCSP is tested first, and if it replies and the answer is invalid, then you don't have the EV UI, no fallback to CRL is decided. That's what happens when I'm visiting servicios.izenpe.com with my Mac (up to date). If there's no OCSP reply, then a CRL is downloaded.
On Opera, the intermediate CA is validated by downloading the CRL, so the non conformant OCSP is not seen.

So, as described, the OCSP issues are hidden, that doesn't mean they don't exist. CABForum asks you (as a CA) to have a functional OCSP service; it's not; you fail.

> 2.- According to the interpretation of the RFC 2560 from Mozilla, that we
> didn´t share, we created a new VA exclusively for the CA that issues the EV and
> thru port 80.

What don't you share? The fact that an OCSP reply can eventually be signed by a third party if and only if correctly declared on the browser side? It has been defined that way since 11 years now. This RFC has some weak points, I agree, but not on that particular point.

> So, when this was done, it was tested by Mozilla and everything
> seemed ok. Some test builds were created and sent to us for checking and the
> results were correct
> 3.- Then a new requirement came to the show, nothing that we were aware of, and
> I read that we can´t be included because the requirements have changed

Could you elaborate on this? Requirements on a functional OCSP service hasn't changed lately, and I don't remember having read that tests with Mozilla were OK.

> Answers to some questions
> -    Our root CA and subordinate CAs are signed with SHA1 and SHA256 all of
> them, and I applied for including “both” roots but it was suggested (like the
> other browsers) to include only the newest, the SHA256 signed. By default, the
> issuing CAs use the SHA1, just in case waiting for a broader use of the SHA256,
> but this is not an issue nor a problem or mistake. It could be strange as
> Erwann says but it´s what has been suggested.

What I found strange is having the SHA256 one referenced, and sending the SHA1 one in replies (this is useless to send a root in a certificate chain, as you can't send *Trust* associated with it). Either do SHA1 or SHA256, but be consistent. There's no security problem with SHA1 right now, there can be deployment issues with SHA256 if you're dealing with pre-WindowsXP-SP3 customers.

> And, on the end, I can´t believe this situation in general. More than 4 years
> for this, no problems with the other browsers, being certified in ISO, ETSI and
> Webtrust, plus some government auditing criteria as we are a Government CA,
> being the only CA with 2 EV OIDs and recognized for being one of the most
> secure and securized one (root CA and issuing CAs with 4K length and SHA1 and
> SHA2 signed) and so on. Unbelievably

You're not following the standards, and don't understand basic security points.
For example:
 - how can you think that an OCSP responder signed by a completely different (unknown, so untrusted) CA could be considered as trustful to sign an OCSP reply?
 - how can you still continue to deliver certificates with sequential serial numbers, when we know since 2004 that this is the best defense against collision attacks on hash functions? (that's a no-no for Opera, for example, and I don't understand how they have validated that)

2 optional questions, not really technical ones, only marketing:
 - can you argument how a 4K key is "better" than a 2K key? (is a rabbit "more dead" if I shoot it with a rocket instead of a riffle?)
 - can you argument how a SHA256 *root* CA is "better" than a SHA1 one, when no attack on second pre-image exist on SHA1, but only some theoritical collision ones?
Erwann,

I´ve just checked with my MAC OS 10.6.5 and I can see https://servicios.izenpe.com and https://servicios1.izenpe.com in green.

Regards
Guys,

we finally updated our VA infraestructure according to your requirements. And to avoid any issue we tested in the minefield and it worked.
Attached you´ll find the result.

Regards
Attached file Minefield report — 
Result from the Minefeld for the https://servicios.izenpe.com site
(In reply to comment #28)
> we finally updated our VA infraestructure according to your requirements. And
> to avoid any issue we tested in the minefield and it worked.
> Attached you´ll find the result.

I validated the 2 OCSP responders (to validate servicios.izenpe.com, and "CA de Certificados SSL EV"), both are OK.

For the lowest level (to validate webserver certificates), the OCSP reply doesn't have the nextUpdate field (which is perfectly valid, it is defined as OPTIONAL). If I correctly read Firefox source code, then this OCSP reply will be taken as valid for 24 hours.
Test websites for enabling EV for the Izenpe.com root: 
EV OID 1.3.6.1.4.1.14777.6.1.1  --  https://servicios.izenpe.com
EV OID 1.3.6.1.4.1.14777.6.1.2 --  https://servicios1.izenpe.com

I just tested these again, and I am able to browse to these two websites without error in FF 4.0 with OCSP enforced. AIA has OCSP: URI: http://ocsp.izenpe.com
Yes, my testing also got a success.

I missed to include this change in my today's new test build.
But this shouldn't be a problem.

I will use the exact patch (from bug 614852 patch v1), which I had used to produce the earlier test build, which Izenpe had used to do their recent testing.
Depends on: 642144
Hi,

any date when FF4 is going to be released? I´ve seen that now is in RC. When released, is it displaying the EV also?

Regards
fixed in bug 642144
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Hi,

sorry i ask here, but i could not find any where that might have information, I want to know how could i contact izenpe support or sales? I want to buy some of their SSLs
(In reply to hamedkh from comment #35)
> Hi,
> 
> sorry i ask here, but i could not find any where that might have
> information, I want to know how could i contact izenpe support or sales? I
> want to buy some of their SSLs

http://www.izenpe.com/
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: