Hi Volkan,
Look at RFC2560/6960 section A.1, describing the format of a request sent over
HTTP:
An OCSP request using the GET method is constructed as follows:
GET {url}/{url-encoding of base-64 encoding of the DER encoding of
the OCSPRequest}
That is, some characters from the base64 representation of the request are
transformed:
/ is transformed into %2F
+ is transformed into %2B
= is transformed into %3D
and your OCSP responder is supposed to reverse that transformation (only once),
then base-64 decode the string, and continue with the process (OCSP request
parsing, etc).
It seems your OCSP responder doesn't accept URL-encoded OCSP requests, or at
least the "%2F".
For exemple,
http://ocsp.turktrust.com.tr/MG8wbTBGMEQwQjAJBgUrDgMCGgUABBQQ2AK0bL%2FGhSj1k0wefmhq3OpH2QQUm2YLShhBeYBnKwY4pSPDzSCPzccCCQFsT3pmwByBWqIjMCEwHwYJKwYBBQUHMAECBBIEEHVUJl9ozL9EVAJGSJJt7yA%3D
gives a 400 error, and if I change "%2F" into "/", I get an OCSP response.
May this can help you: I think this is the same error that Mr Erwann Abalea
detected on this OCSP Responder in May 2012 (See "TURKTRUST Additional Root
Inclusion Request" discussion).
Cheers,
J
El miércoles, 4 de marzo de 2015, 17:33:02 (UTC+1), Volkan Nergiz escribió:
> Hi All,
>
> #1: As far as we know, our OCSP server already works with HTTP GET requests.
> When we analyze the logs, we see many GET requests that are being responded
> successfully.
>
> For example, we have generated the OCSP request below, using the openssl
> tool, for the certificate of https://testsuite12002.turktrust.com.tr/
>
> MG8wbTBGMEQwQjAJBgUrDgMCGgUABBQQ2AK0bL/GhSj1k0wefmhq3OpH2QQUm2YLShhBeYBnKwY4pSPDzSCPzccCCQFsT3pmwByBWqIjMCEwHwYJKwYBBQUHMAECBBIEEHVUJl9ozL9EVAJGSJJt7yA=
>
> When we paste this request to the address bar of Firefox 36.0 as:
>
> http://ocsp.turktrust.com.tr/MG8wbTBGMEQwQjAJBgUrDgMCGgUABBQQ2AK0bL/GhSj1k0wefmhq3OpH2QQUm2YLShhBeYBnKwY4pSPDzSCPzccCCQFsT3pmwByBWqIjMCEwHwYJKwYBBQUHMAECBBIEEHVUJl9ozL9EVAJGSJJt7yA=
>
> we get a successful "good" answer using HTTP GET.
>
> Could you please share with us the name of the OCSP client tool and the
> content of the request, or any other clue that made you think that our OCSP
> server does not support HTTP GET?
>
> Best Regards,
>
> Volkan Nergiz
> TURKTRUST, Inc.
>
> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+volkan.nergiz=turktrust.com...@lists.mozilla.org]
> On Behalf Of Jesus F
> Sent: Tuesday, March 3, 2015 6:28 PM
> To: [email protected]
> Subject: Re: TurkTrust Root Renewal Request
>
> Hi all,
>
> After some quick test of the OCSP Service I detect the following issues
> related to the conformity with CA/Browser Forum Baseline Requirements for the
> Issuance and Management of Publicly-Trusted Certificates (hereinafter BR) as
> required by section 12 of Mozilla CA Certificate Inclusion Policy v2.2:
>
> Test site: https://testsuite12001.turktrust.com.tr
> Test site: https://testsuite12002.turktrust.com.tr
> Ocsp: http://ocsp.turktrust.com.tr/
>
> #1: OCSP do not respond using GET method. (BR section 13.2.2)
> #2: Although the OCSP do not respond "good" to a non-issued certifcate
> (serials FFFFFFFFFFFFFFFFFF and 000000000000000000) (BR Section 13.2.6), it
> responds "unknown". This is not in accordance with RFC 6960 (section 2.2)
> contrary to what is stated in section 7.3 of the CP
> (http://dl.turktrust.com.tr/pdf/TURKTRUST-CP-v09-SSL.pdf)
>
> Cheers,
> J
>
>
>
> El martes, 3 de marzo de 2015, 16:37:21 (UTC+1), Volkan Nergiz escribió:
> > Dear All,
> >
> >
> >
> > The issue is actually quite clear and explicitly stated in TURKTRUST
> > CP and CPS documents. Please see
> > <http://dl.turktrust.com.tr/pdf/TURKTRUST-CP-v09-SSL.pdf>
> > http://dl.turktrust.com.tr/pdf/TURKTRUST-CP-v09-SSL.pdf and
> > <http://dl.turktrust.com.tr/pdf/TURKTRUST-CPS-v09-SSL.pdf>
> > http://dl.turktrust.com.tr/pdf/TURKTRUST-CPS-v09-SSL.pdf for the
> > English versions of TURKTRUST CP and CPS regarding SSL, EV SSL and
> > Object Signing
> > (OSC) certificate services.
> >
> >
> >
> > Currently, TURKTRUST has three explicit OIDs for SSL, EV SSL and OSC
> > certificates as follows with dedicated policies:
> >
> >
> >
> > 1. TURKTRUST SSL Certificate Policy (2.16.792.3.0.3.1.1.2) covers
> > OV SSL certificates for servers. SSL Certificates are issued and
> > maintained in conformity with "Normalized Certificate Policy" defined
> > in ETSI TS 102 042.
> >
> > 2. TURKTRUST OSC Policy (2.16.792.3.0.3.1.1.4) covers
> > certificates related to object signing operations. OSC is issued and
> > maintained in conformity with "Normalized Certificate Policy" defined
> > in ETSI TS 102 042.
> >
> > 3. TURKTRUST EV SSL Policy (2.16.792.3.0.3.1.1.5) covers
> > certificates related to EV SSL certificates. EV SSL certificates are
> > issued and maintained in conformity with ""Extended Validity Certificate
> > Policy"
> > defined in ETSI TS 102 042.
> >
> >
> >
> > For EV SSL services, we have a separate EV root in our new hierarchies
> > as mandated by the CA/Browser Forum EV Guidelines. This is the
> > "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H6" root certificate.
> >
> >
> >
> > For OV SSL and code signing (OSC), we have another separate root
> > certificate, namely "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5"
> > root certificate.
> >
> >
> >
> > For our qualified electronic certificate (QEC) services related to our
> > e-signature based operations, we have a totally different root called H4.
> > This is out of discussion in this context.
> >
> >
> >
> > Hence, the primary distinction related to our discussion is that we
> > have two separate roots for EV SSL services and the others.
> >
> >
> >
> > The second distinction is that, we have separate sub-root certificates, i.e.
> > intermediate certificates, for our OV SSL and OSC certificate
> > services under the root H5. That is to say, all certificate types have
> > different policies, different OIDs, different intermediates and
> > different operational processes.
> >
> >
> >
> > We hope, these explanations clarify the issue for all. Should you have
> > and further questions, please do not hesitate to contact us.
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Volkan NERGİZ
> >
> >
> > Quality Management System Specialist
> >
> >
> >
> >
> >
> > TURKTRUST Information Security Services Inc.
> >
> > Address: Hollanda Caddesi 696. Sokak No: 7 Yıldız, Çankaya 06550 -
> > ANKARA
> >
> > Phone: (312) 439 10 00 - 226 Fax: (312) 439 10 01
> >
> > E-Mail: <mailto:[email protected]>
> > [email protected]
> >
> > Web: <http://www.turktrust.com.tr/> www.turktrust.com.tr
> _______________________________________________
> dev-security-policy mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
