You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Sterpu Victor <vi...@caido.ro> on 2015/08/23 08:51:10 UTC
[users@httpd] SSL - How client certificates are verified?
Hello
I have a web page that asks for client certificate.
These are the options for this:
SSLVerifyClient require
SSLVerifyDepth 10
How does SSLVerifyClient verifies the client certificate?
This option protects against certificates manual made with a fake
public-private key pair?
So can someoane make a certificate identical with the original, attach
another set of public and private keys and pretend to be someoane else?
Thank you
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re[2]: [users@httpd] SSL - How client certificates are verified?
Posted by Sterpu Victor <vi...@caido.ro>.
I want to make a page that will authenticate only with PKCS11 tokens.
These tokens contain only certificates from a recognized authority.
OCSP would be usefull if the token has been declared lost or stolen.
But I don't want to make things too complicated.
------ Original Message ------
From: "Marat Khalili" <mk...@rqc.ru>
To: users@httpd.apache.org
Sent: 8/23/2015 6:51:02 PM
Subject: Re: [users@httpd] SSL - How client certificates are verified?
>Hello, what is your scenario? If you issue (sign) client certificates
>yourself, Apache can correctly verify it against local CRL (certificate
>revocation list) file (server restart may be required after file
>update). There's information in the net concerning OCSP support for
>client authentication in newer versions of Apache (google
>SSLOCSPEnable), but I can see no real use for it save for some very
>complicated systems.
>-- With Best Regards, Marat Khalili
>On 23/08/2015 09:51, Sterpu Victor wrote:
>>Hello
>>
>>I have a web page that asks for client certificate.
>>These are the options for this:
>>
>>SSLVerifyClient require
>>SSLVerifyDepth 10
>>
>>How does SSLVerifyClient verifies the client certificate?
>>This option protects against certificates manual made with a fake
>>public-private key pair?
>>So can someoane make a certificate identical with the original, attach
>>another set of public and private keys and pretend to be someoane
>>else?
>>
>>Thank you
>>
>>
>>--------------------------------------------------------------------------------
>>This email has been checked for viruses by Avast antivirus software.
>>www.avast.com
>>
>>
>>
>>DISCLAIMER:
>>Acest mesaj de posta electronica si documentele aferente sunt
>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt
>>mod de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj,
>>este interzis sa actionati in baza acestor informatii. Citirea,
>>copierea, distribuirea, dezvaluirea sau utilizarea in alt mod a
>>informatiei continute in acest mesaj constituie o incalcare a legii.
>>Daca ati primit mesajul din greseala, va rugam sa il distrugeti,
>>anuntand expeditorul de eroarea comisa. Intrucat nu poate fi garantat
>>faptul ca posta electronica este un mod sigur si lipsit de erori de
>>transmitere a informatiilor, este responsabilitatea dvs. sa va
>>asigurati ca mesajul (inclusiv documentele alaturate lui) este validat
>>si autorizat spre a fi utilizat in mediul dvs.
>>
>>
>
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re[2]: [users@httpd] SSL - How client certificates are verified?
Posted by Sterpu Victor <vi...@caido.ro>.
Ok.
------ Original Message ------
From: "Marat Khalili" <mk...@rqc.ru>
To: users@httpd.apache.org
Sent: 8/23/2015 8:16:06 PM
Subject: Re: [users@httpd] SSL - How client certificates are verified?
>In this case, could you please post the results when you get the
>SSLOCSPEnable fixed? I'm particularly interested in performance.
>-- With Best Regards, Marat Khalili
>On 23/08/2015 19:57, Sterpu Victor wrote:
>>There are 4 CAs, at least 1 uses OCSP(only 1 I called).
>>I hope all of them use OCSP, I don't know the legislation but it seems
>>normal to be required by law.
>>
>>------ Original Message ------
>>From: "Marat Khalili" <mk...@rqc.ru>
>>To: users@httpd.apache.org
>>Sent: 8/23/2015 7:51:14 PM
>>Subject: Re: [users@httpd] SSL - How client certificates are verified?
>>
>>>Oh, I see. In this case you will have to check the status of their
>>>certificates. Still, I suspect all of the tokens are issued by one
>>>CA. Probably it is better to ask this CA for their procedures: do
>>>they use OCSP or just publish CRLs.
>>>-- With Best Regards, Marat Khalili
>>>On 23/08/2015 19:41, Sterpu Victor wrote:
>>>>All clients already have PKCS11 tokens.
>>>>It would be too complicated for them to get used with something
>>>>else.
>>>>
>>>>------ Original Message ------
>>>>From: "Marat Khalili" <mk...@rqc.ru>
>>>>To: users@httpd.apache.org
>>>>Sent: 8/23/2015 7:34:07 PM
>>>>Subject: Re: [users@httpd] SSL - How client certificates are
>>>>verified?
>>>>
>>>>>I see. However, accepting clients certificates from the world
>>>>>recognized authorities is both more expensive (for clients) and
>>>>>more risky than running your own CA (recognized only by your
>>>>>server). If you personally know all your clients it is easier to
>>>>>issue them certificates directly, and revoke them by yourself too
>>>>>if needed.
>>>>>-- With Best Regards, Marat Khalili
>>>>>On 23/08/2015 18:56, Sterpu Victor wrote:
>>>>>>I want to make a page that will authenticate only with PKCS11
>>>>>>tokens.
>>>>>>These tokens contain only certificates from a recognized
>>>>>>authority.
>>>>>>OCSP would be usefull if the token has been declared lost or
>>>>>>stolen.
>>>>>>But I don't want to make things too complicated.
>>>>>>
>>>>>>
>>>>>>------ Original Message ------
>>>>>>From: "Marat Khalili" <mk...@rqc.ru>
>>>>>>To: users@httpd.apache.org
>>>>>>Sent: 8/23/2015 6:51:02 PM
>>>>>>Subject: Re: [users@httpd] SSL - How client certificates are
>>>>>>verified?
>>>>>>
>>>>>>>Hello, what is your scenario? If you issue (sign) client
>>>>>>>certificates yourself, Apache can correctly verify it against
>>>>>>>local CRL (certificate revocation list) file (server restart may
>>>>>>>be required after file update). There's information in the net
>>>>>>>concerning OCSP support for client authentication in newer
>>>>>>>versions of Apache (google SSLOCSPEnable), but I can see no real
>>>>>>>use for it save for some very complicated systems.
>>>>>>>-- With Best Regards, Marat Khalili
>>>>>>>On 23/08/2015 09:51, Sterpu Victor wrote:
>>>>>>>>Hello
>>>>>>>>
>>>>>>>>I have a web page that asks for client certificate.
>>>>>>>>These are the options for this:
>>>>>>>>
>>>>>>>>SSLVerifyClient require
>>>>>>>>SSLVerifyDepth 10
>>>>>>>>
>>>>>>>>How does SSLVerifyClient verifies the client certificate?
>>>>>>>>This option protects against certificates manual made with a
>>>>>>>>fake public-private key pair?
>>>>>>>>So can someoane make a certificate identical with the original,
>>>>>>>>attach another set of public and private keys and pretend to be
>>>>>>>>someoane else?
>>>>>>>>
>>>>>>>>Thank you
>>>>>>>>
>>>>>>>>
>>>>>>>>--------------------------------------------------------------------------------
>>>>>>>>This email has been checked for viruses by Avast antivirus
>>>>>>>>software.
>>>>>>>>www.avast.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>DISCLAIMER:
>>>>>>>>Acest mesaj de posta electronica si documentele aferente sunt
>>>>>>>>confidentiale. Este interzisa distribuirea, dezvaluirea sau
>>>>>>>>orice alt mod de utilizare a lor. Daca nu sunteti destinatarul
>>>>>>>>acestui mesaj, este interzis sa actionati in baza acestor
>>>>>>>>informatii. Citirea, copierea, distribuirea, dezvaluirea sau
>>>>>>>>utilizarea in alt mod a informatiei continute in acest mesaj
>>>>>>>>constituie o incalcare a legii. Daca ati primit mesajul din
>>>>>>>>greseala, va rugam sa il distrugeti, anuntand expeditorul de
>>>>>>>>eroarea comisa. Intrucat nu poate fi garantat faptul ca posta
>>>>>>>>electronica este un mod sigur si lipsit de erori de transmitere
>>>>>>>>a informatiilor, este responsabilitatea dvs. sa va asigurati ca
>>>>>>>>mesajul (inclusiv documentele alaturate lui) este validat si
>>>>>>>>autorizat spre a fi utilizat in mediul dvs.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>--------------------------------------------------------------------------------
>>>>>>This email has been checked for viruses by Avast antivirus
>>>>>>software.
>>>>>>www.avast.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>DISCLAIMER:
>>>>>>Acest mesaj de posta electronica si documentele aferente sunt
>>>>>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>>>>>alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>>>>>mesaj, este interzis sa actionati in baza acestor informatii.
>>>>>>Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>>>>>mod a informatiei continute in acest mesaj constituie o incalcare
>>>>>>a legii. Daca ati primit mesajul din greseala, va rugam sa il
>>>>>>distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>>>>>poate fi garantat faptul ca posta electronica este un mod sigur si
>>>>>>lipsit de erori de transmitere a informatiilor, este
>>>>>>responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>>>>>documentele alaturate lui) este validat si autorizat spre a fi
>>>>>>utilizat in mediul dvs.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>--------------------------------------------------------------------------------
>>>>This email has been checked for viruses by Avast antivirus software.
>>>>www.avast.com
>>>>
>>>>
>>>>
>>>>DISCLAIMER:
>>>>Acest mesaj de posta electronica si documentele aferente sunt
>>>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>>>alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>>>mesaj, este interzis sa actionati in baza acestor informatii.
>>>>Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>>>mod a informatiei continute in acest mesaj constituie o incalcare a
>>>>legii. Daca ati primit mesajul din greseala, va rugam sa il
>>>>distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>>>poate fi garantat faptul ca posta electronica este un mod sigur si
>>>>lipsit de erori de transmitere a informatiilor, este
>>>>responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>>>documentele alaturate lui) este validat si autorizat spre a fi
>>>>utilizat in mediul dvs.
>>>>
>>>>
>>>
>>
>>
>>--------------------------------------------------------------------------------
>>This email has been checked for viruses by Avast antivirus software.
>>www.avast.com
>>
>>
>>
>>DISCLAIMER:
>>Acest mesaj de posta electronica si documentele aferente sunt
>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt
>>mod de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj,
>>este interzis sa actionati in baza acestor informatii. Citirea,
>>copierea, distribuirea, dezvaluirea sau utilizarea in alt mod a
>>informatiei continute in acest mesaj constituie o incalcare a legii.
>>Daca ati primit mesajul din greseala, va rugam sa il distrugeti,
>>anuntand expeditorul de eroarea comisa. Intrucat nu poate fi garantat
>>faptul ca posta electronica este un mod sigur si lipsit de erori de
>>transmitere a informatiilor, este responsabilitatea dvs. sa va
>>asigurati ca mesajul (inclusiv documentele alaturate lui) este validat
>>si autorizat spre a fi utilizat in mediul dvs.
>>
>>
>
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: Re[2]: [users@httpd] SSL - How client certificates are verified?
Posted by Anne Blankert <an...@geodan.nl>.
The problem is not in the client certificate but in the issuer certicates
aka known as the certificate chain.
I was able to solve the problem by adding the following line in my Apache
server configuration:
SSLCACertificateFile /etc/ssl/certs/clientcertificatechain.pem
where file 'clientcertificatechain.pem' contains all the intermediate
certificates for the client certificate.
2015-08-26 11:44 GMT+02:00 Sterpu Victor <vi...@caido.ro>:
> The certificates are already on the server.
>
> ------ Original Message ------
> From: "Marat Khalili" <mk...@rqc.ru>
> To: users@httpd.apache.org
> Sent: 8/26/2015 11:34:24 AM
> Subject: Re: [users@httpd] SSL - How client certificates are verified?
>
>
> I'm only guessing, but maybe manually adding all necessary intermediate
> certificates to your server will help?
>
> --
>
> With Best Regards,
> Marat Khalili
>
>
> On 26/08/15 09:31, Sterpu Victor wrote:
>
> I installed apache 2.4.16 and I have activated SSLOCSPEnable on a virtual
> domain but the page is not loading at all with OCSPEnabled(without OCSP is
> working).
>
> The error is:
> SSL Library Error: error:27069065:OCSP
> routines:OCSP_basic_verify:certificate verify error (Verify error:unable to
> get local issuer certificate)
> AH02039: Certificate Verification: Error (50): application verification
> failure
> AH01925: failed to verify the OCSP response
> I would use SSLOCSPOverrideResponder
> <http://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslocspoverrideresponder> but
> I have 4 different OCSP servers depending on the CA.
> I checked the certificates and in the section Authority Information
> Access there is a URL to the OCSP server.
> This is the information from one of the certificates:
>
> [1]Authority Info Access
> Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
> Alternative Name:
> URL=http://ocsp.certsign.ro/ocsp
>
> ocsp.digisign.ro is answering on port 80.
> Could be a problem with SSLOCSPEnable that is not auto extracting the
> OCSP URL?
>
> My configuration is:
> SSLEngine on
> SSLCertificateFile /etc/ssl/card.casnt.ro/server.crt
> SSLCertificateKeyFile /etc/ssl/card.casnt.ro/server.key
> SSLCACertificateFile /etc/ssl/certs/RO/All_Certs.pem
>
> SSLVerifyClient require
> SSLVerifyDepth 10
> SSLOptions +StdEnvVars +ExportCertData
> SSLOCSPEnable On
>
> Thank you.
>
> ------ Original Message ------
> From: "Marat Khalili" <mk...@rqc.ru>
> To: users@httpd.apache.org
> Sent: 8/23/2015 8:16:06 PM
> Subject: Re: [users@httpd] SSL - How client certificates are verified?
>
>
> In this case, could you please post the results when you get the
> SSLOCSPEnable fixed? I'm particularly interested in performance.
>
> --
>
> With Best Regards,
> Marat Khalili
>
>
> On 23/08/2015 19:57, Sterpu Victor wrote:
>
> There are 4 CAs, at least 1 uses OCSP(only 1 I called).
> I hope all of them use OCSP, I don't know the legislation but it seems
> normal to be required by law.
>
> ------ Original Message ------
> From: "Marat Khalili" <mk...@rqc.ru>
> To: users@httpd.apache.org
> Sent: 8/23/2015 7:51:14 PM
> Subject: Re: [users@httpd] SSL - How client certificates are verified?
>
>
> Oh, I see. In this case you will have to check the status of their
> certificates. Still, I suspect all of the tokens are issued by one CA.
> Probably it is better to ask this CA for their procedures: do they use OCSP
> or just publish CRLs.
>
> --
>
> With Best Regards,
> Marat Khalili
>
>
> On 23/08/2015 19:41, Sterpu Victor wrote:
>
> All clients already have PKCS11 tokens.
> It would be too complicated for them to get used with something else.
>
> ------ Original Message ------
> From: "Marat Khalili" <mk...@rqc.ru>
> To: users@httpd.apache.org
> Sent: 8/23/2015 7:34:07 PM
> Subject: Re: [users@httpd] SSL - How client certificates are verified?
>
>
> I see. However, accepting clients certificates from the world recognized
> authorities is both more expensive (for clients) and more risky than
> running your own CA (recognized only by your server). If you personally
> know all your clients it is easier to issue them certificates directly, and
> revoke them by yourself too if needed.
>
> --
>
> With Best Regards,
> Marat Khalili
>
>
> On 23/08/2015 18:56, Sterpu Victor wrote:
>
> I want to make a page that will authenticate only with PKCS11 tokens.
> These tokens contain only certificates from a recognized authority.
> OCSP would be usefull if the token has been declared lost or stolen.
> But I don't want to make things too complicated.
>
>
> ------ Original Message ------
> From: "Marat Khalili" <mk...@rqc.ru>
> To: users@httpd.apache.org
> Sent: 8/23/2015 6:51:02 PM
> Subject: Re: [users@httpd] SSL - How client certificates are verified?
>
>
> Hello, what is your scenario? If you issue (sign) client certificates
> yourself, Apache can correctly verify it against local CRL (certificate
> revocation list) file (server restart may be required after file update).
> There's information in the net concerning OCSP support for client
> authentication in newer versions of Apache (google SSLOCSPEnable), but I
> can see no real use for it save for some very complicated systems.
>
> --
>
> With Best Regards,
> Marat Khalili
>
>
> On 23/08/2015 09:51, Sterpu Victor wrote:
>
> Hello
>
> I have a web page that asks for client certificate.
> These are the options for this:
>
> SSLVerifyClient require
> SSLVerifyDepth 10
>
> How does SSLVerifyClient verifies the client certificate?
> This option protects against certificates manual made with a fake
> public-private key pair?
> So can someoane make a certificate identical with the original, attach
> another set of public and private keys and pretend to be someoane else?
>
> Thank you
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
>
> *DISCLAIMER: Acest mesaj de posta electronica si documentele aferente sunt
> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt mod
> de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj, este
> interzis sa actionati in baza acestor informatii. Citirea, copierea,
> distribuirea, dezvaluirea sau utilizarea in alt mod a informatiei continute
> in acest mesaj constituie o incalcare a legii. Daca ati primit mesajul din
> greseala, va rugam sa il distrugeti, anuntand expeditorul de eroarea
> comisa. Intrucat nu poate fi garantat faptul ca posta electronica este un
> mod sigur si lipsit de erori de transmitere a informatiilor, este
> responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv documentele
> alaturate lui) este validat si autorizat spre a fi utilizat in mediul dvs.*
>
>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
>
> *DISCLAIMER: Acest mesaj de posta electronica si documentele aferente sunt
> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt mod
> de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj, este
> interzis sa actionati in baza acestor informatii. Citirea, copierea,
> distribuirea, dezvaluirea sau utilizarea in alt mod a informatiei continute
> in acest mesaj constituie o incalcare a legii. Daca ati primit mesajul din
> greseala, va rugam sa il distrugeti, anuntand expeditorul de eroarea
> comisa. Intrucat nu poate fi garantat faptul ca posta electronica este un
> mod sigur si lipsit de erori de transmitere a informatiilor, este
> responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv documentele
> alaturate lui) este validat si autorizat spre a fi utilizat in mediul dvs.*
>
>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
>
> *DISCLAIMER: Acest mesaj de posta electronica si documentele aferente sunt
> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt mod
> de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj, este
> interzis sa actionati in baza acestor informatii. Citirea, copierea,
> distribuirea, dezvaluirea sau utilizarea in alt mod a informatiei continute
> in acest mesaj constituie o incalcare a legii. Daca ati primit mesajul din
> greseala, va rugam sa il distrugeti, anuntand expeditorul de eroarea
> comisa. Intrucat nu poate fi garantat faptul ca posta electronica este un
> mod sigur si lipsit de erori de transmitere a informatiilor, este
> responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv documentele
> alaturate lui) este validat si autorizat spre a fi utilizat in mediul dvs.*
>
>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
>
> *DISCLAIMER: Acest mesaj de posta electronica si documentele aferente sunt
> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt mod
> de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj, este
> interzis sa actionati in baza acestor informatii. Citirea, copierea,
> distribuirea, dezvaluirea sau utilizarea in alt mod a informatiei continute
> in acest mesaj constituie o incalcare a legii. Daca ati primit mesajul din
> greseala, va rugam sa il distrugeti, anuntand expeditorul de eroarea
> comisa. Intrucat nu poate fi garantat faptul ca posta electronica este un
> mod sigur si lipsit de erori de transmitere a informatiilor, este
> responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv documentele
> alaturate lui) este validat si autorizat spre a fi utilizat in mediul dvs.*
>
>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
>
> *DISCLAIMER: Acest mesaj de posta electronica si documentele aferente sunt
> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt mod
> de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj, este
> interzis sa actionati in baza acestor informatii. Citirea, copierea,
> distribuirea, dezvaluirea sau utilizarea in alt mod a informatiei continute
> in acest mesaj constituie o incalcare a legii. Daca ati primit mesajul din
> greseala, va rugam sa il distrugeti, anuntand expeditorul de eroarea
> comisa. Intrucat nu poate fi garantat faptul ca posta electronica este un
> mod sigur si lipsit de erori de transmitere a informatiilor, este
> responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv documentele
> alaturate lui) este validat si autorizat spre a fi utilizat in mediul dvs.*
>
>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
>
> *DISCLAIMER: Acest mesaj de posta electronica si documentele aferente sunt
> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt mod
> de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj, este
> interzis sa actionati in baza acestor informatii. Citirea, copierea,
> distribuirea, dezvaluirea sau utilizarea in alt mod a informatiei continute
> in acest mesaj constituie o incalcare a legii. Daca ati primit mesajul din
> greseala, va rugam sa il distrugeti, anuntand expeditorul de eroarea
> comisa. Intrucat nu poate fi garantat faptul ca posta electronica este un
> mod sigur si lipsit de erori de transmitere a informatiilor, este
> responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv documentele
> alaturate lui) este validat si autorizat spre a fi utilizat in mediul dvs.*
>
>
Re[2]: [users@httpd] SSL - How client certificates are verified?
Posted by Sterpu Victor <vi...@caido.ro>.
The certificates are already on the server.
------ Original Message ------
From: "Marat Khalili" <mk...@rqc.ru>
To: users@httpd.apache.org
Sent: 8/26/2015 11:34:24 AM
Subject: Re: [users@httpd] SSL - How client certificates are verified?
>I'm only guessing, but maybe manually adding all necessary intermediate
>certificates to your server will help?
>-- With Best Regards, Marat Khalili
>On 26/08/15 09:31, Sterpu Victor wrote:
>>I installed apache 2.4.16 and I have activated SSLOCSPEnable on a
>>virtual domain but the page is not loading at all with
>>OCSPEnabled(without OCSP is working).
>>
>>The error is:
>>SSL Library Error: error:27069065:OCSP
>>routines:OCSP_basic_verify:certificate verify error (Verify
>>error:unable to get local issuer certificate)
>>AH02039: Certificate Verification: Error (50): application
>>verification failure
>>AH01925: failed to verify the OCSP response
>>I would use SSLOCSPOverrideResponder but I have 4 different OCSP
>>servers depending on the CA.
>>I checked the certificates and in the section Authority Information
>>Access there is a URL to the OCSP server.
>>This is the information from one of the certificates:
>>>[1]Authority Info Access
>>>Access Method=On-line Certificate Status Protocol
>>>(1.3.6.1.5.5.7.48.1)
>>>Alternative Name:
>>>URL=http://ocsp.certsign.ro/ocsp
>>ocsp.digisign.ro is answering on port 80.
>>Could be a problem with SSLOCSPEnable that is not auto extracting the
>>OCSP URL?
>>
>>My configuration is:
>> SSLEngine on
>> SSLCertificateFile /etc/ssl/card.casnt.ro/server.crt
>> SSLCertificateKeyFile /etc/ssl/card.casnt.ro/server.key
>> SSLCACertificateFile /etc/ssl/certs/RO/All_Certs.pem
>>
>> SSLVerifyClient require
>> SSLVerifyDepth 10
>> SSLOptions +StdEnvVars +ExportCertData
>> SSLOCSPEnable On
>>
>>Thank you.
>>
>>------ Original Message ------
>>From: "Marat Khalili" <mk...@rqc.ru>
>>To: users@httpd.apache.org
>>Sent: 8/23/2015 8:16:06 PM
>>Subject: Re: [users@httpd] SSL - How client certificates are verified?
>>
>>>In this case, could you please post the results when you get the
>>>SSLOCSPEnable fixed? I'm particularly interested in performance.
>>>-- With Best Regards, Marat Khalili
>>>On 23/08/2015 19:57, Sterpu Victor wrote:
>>>>There are 4 CAs, at least 1 uses OCSP(only 1 I called).
>>>>I hope all of them use OCSP, I don't know the legislation but it
>>>>seems normal to be required by law.
>>>>
>>>>------ Original Message ------
>>>>From: "Marat Khalili" <mk...@rqc.ru>
>>>>To: users@httpd.apache.org
>>>>Sent: 8/23/2015 7:51:14 PM
>>>>Subject: Re: [users@httpd] SSL - How client certificates are
>>>>verified?
>>>>
>>>>>Oh, I see. In this case you will have to check the status of their
>>>>>certificates. Still, I suspect all of the tokens are issued by one
>>>>>CA. Probably it is better to ask this CA for their procedures: do
>>>>>they use OCSP or just publish CRLs.
>>>>>-- With Best Regards, Marat Khalili
>>>>>On 23/08/2015 19:41, Sterpu Victor wrote:
>>>>>>All clients already have PKCS11 tokens.
>>>>>>It would be too complicated for them to get used with something
>>>>>>else.
>>>>>>
>>>>>>------ Original Message ------
>>>>>>From: "Marat Khalili" <mk...@rqc.ru>
>>>>>>To: users@httpd.apache.org
>>>>>>Sent: 8/23/2015 7:34:07 PM
>>>>>>Subject: Re: [users@httpd] SSL - How client certificates are
>>>>>>verified?
>>>>>>
>>>>>>>I see. However, accepting clients certificates from the world
>>>>>>>recognized authorities is both more expensive (for clients) and
>>>>>>>more risky than running your own CA (recognized only by your
>>>>>>>server). If you personally know all your clients it is easier to
>>>>>>>issue them certificates directly, and revoke them by yourself too
>>>>>>>if needed.
>>>>>>>-- With Best Regards, Marat Khalili
>>>>>>>On 23/08/2015 18:56, Sterpu Victor wrote:
>>>>>>>>I want to make a page that will authenticate only with PKCS11
>>>>>>>>tokens.
>>>>>>>>These tokens contain only certificates from a recognized
>>>>>>>>authority.
>>>>>>>>OCSP would be usefull if the token has been declared lost or
>>>>>>>>stolen.
>>>>>>>>But I don't want to make things too complicated.
>>>>>>>>
>>>>>>>>
>>>>>>>>------ Original Message ------
>>>>>>>>From: "Marat Khalili" <mk...@rqc.ru>
>>>>>>>>To: users@httpd.apache.org
>>>>>>>>Sent: 8/23/2015 6:51:02 PM
>>>>>>>>Subject: Re: [users@httpd] SSL - How client certificates are
>>>>>>>>verified?
>>>>>>>>
>>>>>>>>>Hello, what is your scenario? If you issue (sign) client
>>>>>>>>>certificates yourself, Apache can correctly verify it against
>>>>>>>>>local CRL (certificate revocation list) file (server restart
>>>>>>>>>may be required after file update). There's information in the
>>>>>>>>>net concerning OCSP support for client authentication in newer
>>>>>>>>>versions of Apache (google SSLOCSPEnable), but I can see no
>>>>>>>>>real use for it save for some very complicated systems.
>>>>>>>>>-- With Best Regards, Marat Khalili
>>>>>>>>>On 23/08/2015 09:51, Sterpu Victor wrote:
>>>>>>>>>>Hello
>>>>>>>>>>
>>>>>>>>>>I have a web page that asks for client certificate.
>>>>>>>>>>These are the options for this:
>>>>>>>>>>
>>>>>>>>>>SSLVerifyClient require
>>>>>>>>>>SSLVerifyDepth 10
>>>>>>>>>>
>>>>>>>>>>How does SSLVerifyClient verifies the client certificate?
>>>>>>>>>>This option protects against certificates manual made with a
>>>>>>>>>>fake public-private key pair?
>>>>>>>>>>So can someoane make a certificate identical with the
>>>>>>>>>>original, attach another set of public and private keys and
>>>>>>>>>>pretend to be someoane else?
>>>>>>>>>>
>>>>>>>>>>Thank you
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>--------------------------------------------------------------------------------
>>>>>>>>>>This email has been checked for viruses by Avast antivirus
>>>>>>>>>>software.
>>>>>>>>>>www.avast.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>DISCLAIMER:
>>>>>>>>>>Acest mesaj de posta electronica si documentele aferente sunt
>>>>>>>>>>confidentiale. Este interzisa distribuirea, dezvaluirea sau
>>>>>>>>>>orice alt mod de utilizare a lor. Daca nu sunteti destinatarul
>>>>>>>>>>acestui mesaj, este interzis sa actionati in baza acestor
>>>>>>>>>>informatii. Citirea, copierea, distribuirea, dezvaluirea sau
>>>>>>>>>>utilizarea in alt mod a informatiei continute in acest mesaj
>>>>>>>>>>constituie o incalcare a legii. Daca ati primit mesajul din
>>>>>>>>>>greseala, va rugam sa il distrugeti, anuntand expeditorul de
>>>>>>>>>>eroarea comisa. Intrucat nu poate fi garantat faptul ca posta
>>>>>>>>>>electronica este un mod sigur si lipsit de erori de
>>>>>>>>>>transmitere a informatiilor, este responsabilitatea dvs. sa va
>>>>>>>>>>asigurati ca mesajul (inclusiv documentele alaturate lui) este
>>>>>>>>>>validat si autorizat spre a fi utilizat in mediul dvs.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>--------------------------------------------------------------------------------
>>>>>>>>This email has been checked for viruses by Avast antivirus
>>>>>>>>software.
>>>>>>>>www.avast.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>DISCLAIMER:
>>>>>>>>Acest mesaj de posta electronica si documentele aferente sunt
>>>>>>>>confidentiale. Este interzisa distribuirea, dezvaluirea sau
>>>>>>>>orice alt mod de utilizare a lor. Daca nu sunteti destinatarul
>>>>>>>>acestui mesaj, este interzis sa actionati in baza acestor
>>>>>>>>informatii. Citirea, copierea, distribuirea, dezvaluirea sau
>>>>>>>>utilizarea in alt mod a informatiei continute in acest mesaj
>>>>>>>>constituie o incalcare a legii. Daca ati primit mesajul din
>>>>>>>>greseala, va rugam sa il distrugeti, anuntand expeditorul de
>>>>>>>>eroarea comisa. Intrucat nu poate fi garantat faptul ca posta
>>>>>>>>electronica este un mod sigur si lipsit de erori de transmitere
>>>>>>>>a informatiilor, este responsabilitatea dvs. sa va asigurati ca
>>>>>>>>mesajul (inclusiv documentele alaturate lui) este validat si
>>>>>>>>autorizat spre a fi utilizat in mediul dvs.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>--------------------------------------------------------------------------------
>>>>>>This email has been checked for viruses by Avast antivirus
>>>>>>software.
>>>>>>www.avast.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>DISCLAIMER:
>>>>>>Acest mesaj de posta electronica si documentele aferente sunt
>>>>>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>>>>>alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>>>>>mesaj, este interzis sa actionati in baza acestor informatii.
>>>>>>Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>>>>>mod a informatiei continute in acest mesaj constituie o incalcare
>>>>>>a legii. Daca ati primit mesajul din greseala, va rugam sa il
>>>>>>distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>>>>>poate fi garantat faptul ca posta electronica este un mod sigur si
>>>>>>lipsit de erori de transmitere a informatiilor, este
>>>>>>responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>>>>>documentele alaturate lui) este validat si autorizat spre a fi
>>>>>>utilizat in mediul dvs.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>--------------------------------------------------------------------------------
>>>>This email has been checked for viruses by Avast antivirus software.
>>>>www.avast.com
>>>>
>>>>
>>>>
>>>>DISCLAIMER:
>>>>Acest mesaj de posta electronica si documentele aferente sunt
>>>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>>>alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>>>mesaj, este interzis sa actionati in baza acestor informatii.
>>>>Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>>>mod a informatiei continute in acest mesaj constituie o incalcare a
>>>>legii. Daca ati primit mesajul din greseala, va rugam sa il
>>>>distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>>>poate fi garantat faptul ca posta electronica este un mod sigur si
>>>>lipsit de erori de transmitere a informatiilor, este
>>>>responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>>>documentele alaturate lui) este validat si autorizat spre a fi
>>>>utilizat in mediul dvs.
>>>>
>>>>
>>>
>>
>>
>>--------------------------------------------------------------------------------
>>This email has been checked for viruses by Avast antivirus software.
>>www.avast.com
>>
>>
>>
>>DISCLAIMER:
>>Acest mesaj de posta electronica si documentele aferente sunt
>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt
>>mod de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj,
>>este interzis sa actionati in baza acestor informatii. Citirea,
>>copierea, distribuirea, dezvaluirea sau utilizarea in alt mod a
>>informatiei continute in acest mesaj constituie o incalcare a legii.
>>Daca ati primit mesajul din greseala, va rugam sa il distrugeti,
>>anuntand expeditorul de eroarea comisa. Intrucat nu poate fi garantat
>>faptul ca posta electronica este un mod sigur si lipsit de erori de
>>transmitere a informatiilor, este responsabilitatea dvs. sa va
>>asigurati ca mesajul (inclusiv documentele alaturate lui) este validat
>>si autorizat spre a fi utilizat in mediul dvs.
>>
>>
>
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: [users@httpd] SSL - How client certificates are verified?
Posted by Marat Khalili <mk...@rqc.ru>.
I'm only guessing, but maybe manually adding all necessary intermediate
certificates to your server will help?
--
With Best Regards,
Marat Khalili
On 26/08/15 09:31, Sterpu Victor wrote:
> I installed apache 2.4.16 and I have activated SSLOCSPEnable on a
> virtual domain but the page is not loading at all with
> OCSPEnabled(without OCSP is working).
> The error is:
> SSL Library Error: error:27069065:OCSP
> routines:OCSP_basic_verify:certificate verify error (Verify
> error:unable to get local issuer certificate)
> AH02039: Certificate Verification: Error (50): application
> verification failure
> AH01925: failed to verify the OCSP response
> I would use SSLOCSPOverrideResponder
> <http://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslocspoverrideresponder> but
> I have 4 different OCSP servers depending on the CA.
> I checked the certificates and in the section Authority Information
> Access there is a URL to the OCSP server.
> This is the information from one of the certificates:
>
> [1]Authority Info Access
> Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
> Alternative Name:
> URL=http://ocsp.certsign.ro/ocsp
>
> ocsp.digisign.ro is answering on port 80.
> Could be a problem with SSLOCSPEnable that is not auto extracting the
> OCSP URL?
> My configuration is:
> SSLEngine on
> SSLCertificateFile /etc/ssl/card.casnt.ro/server.crt
> SSLCertificateKeyFile /etc/ssl/card.casnt.ro/server.key
> SSLCACertificateFile /etc/ssl/certs/RO/All_Certs.pem
> SSLVerifyClient require
> SSLVerifyDepth 10
> SSLOptions +StdEnvVars +ExportCertData
> SSLOCSPEnable On
> Thank you.
> ------ Original Message ------
> From: "Marat Khalili" <mkh@rqc.ru <ma...@rqc.ru>>
> To: users@httpd.apache.org <ma...@httpd.apache.org>
> Sent: 8/23/2015 8:16:06 PM
> Subject: Re: [users@httpd] SSL - How client certificates are verified?
>> In this case, could you please post the results when you get the
>> SSLOCSPEnable fixed? I'm particularly interested in performance.
>> --
>>
>> With Best Regards,
>> Marat Khalili
>>
>> On 23/08/2015 19:57, Sterpu Victor wrote:
>>> There are 4 CAs, at least 1 uses OCSP(only 1 I called).
>>> I hope all of them use OCSP, I don't know the legislation but it
>>> seems normal to be required by law.
>>> ------ Original Message ------
>>> From: "Marat Khalili" <mkh@rqc.ru <ma...@rqc.ru>>
>>> To: users@httpd.apache.org <ma...@httpd.apache.org>
>>> Sent: 8/23/2015 7:51:14 PM
>>> Subject: Re: [users@httpd] SSL - How client certificates are verified?
>>>> Oh, I see. In this case you will have to check the status of their
>>>> certificates. Still, I suspect all of the tokens are issued by one
>>>> CA. Probably it is better to ask this CA for their procedures: do
>>>> they use OCSP or just publish CRLs.
>>>> --
>>>>
>>>> With Best Regards,
>>>> Marat Khalili
>>>>
>>>> On 23/08/2015 19:41, Sterpu Victor wrote:
>>>>> All clients already have PKCS11 tokens.
>>>>> It would be too complicated for them to get used with something else.
>>>>> ------ Original Message ------
>>>>> From: "Marat Khalili" <mkh@rqc.ru <ma...@rqc.ru>>
>>>>> To: users@httpd.apache.org <ma...@httpd.apache.org>
>>>>> Sent: 8/23/2015 7:34:07 PM
>>>>> Subject: Re: [users@httpd] SSL - How client certificates are verified?
>>>>>> I see. However, accepting clients certificates from the world
>>>>>> recognized authorities is both more expensive (for clients) and
>>>>>> more risky than running your own CA (recognized only by your
>>>>>> server). If you personally know all your clients it is easier to
>>>>>> issue them certificates directly, and revoke them by yourself too
>>>>>> if needed.
>>>>>> --
>>>>>>
>>>>>> With Best Regards,
>>>>>> Marat Khalili
>>>>>>
>>>>>> On 23/08/2015 18:56, Sterpu Victor wrote:
>>>>>>> I want to make a page that will authenticate only with PKCS11
>>>>>>> tokens.
>>>>>>> These tokens contain only certificates from a recognized authority.
>>>>>>> OCSP would be usefull if the token has been declared lost or stolen.
>>>>>>> But I don't want to make things too complicated.
>>>>>>> ------ Original Message ------
>>>>>>> From: "Marat Khalili" <mkh@rqc.ru <ma...@rqc.ru>>
>>>>>>> To: users@httpd.apache.org <ma...@httpd.apache.org>
>>>>>>> Sent: 8/23/2015 6:51:02 PM
>>>>>>> Subject: Re: [users@httpd] SSL - How client certificates are
>>>>>>> verified?
>>>>>>>> Hello, what is your scenario? If you issue (sign) client
>>>>>>>> certificates yourself, Apache can correctly verify it against
>>>>>>>> local CRL (certificate revocation list) file (server restart
>>>>>>>> may be required after file update). There's information in the
>>>>>>>> net concerning OCSP support for client authentication in newer
>>>>>>>> versions of Apache (google SSLOCSPEnable), but I can see no
>>>>>>>> real use for it save for some very complicated systems.
>>>>>>>> --
>>>>>>>>
>>>>>>>> With Best Regards,
>>>>>>>> Marat Khalili
>>>>>>>>
>>>>>>>> On 23/08/2015 09:51, Sterpu Victor wrote:
>>>>>>>>> Hello
>>>>>>>>> I have a web page that asks for client certificate.
>>>>>>>>> These are the options for this:
>>>>>>>>> SSLVerifyClient require
>>>>>>>>> SSLVerifyDepth 10
>>>>>>>>>
>>>>>>>>> How does SSLVerifyClient verifies the client certificate?
>>>>>>>>> This option protects against certificates manual made with a
>>>>>>>>> fake public-private key pair?
>>>>>>>>> So can someoane make a certificate identical with the
>>>>>>>>> original, attach another set of public and private keys and
>>>>>>>>> pretend to be someoane else?
>>>>>>>>> Thank you
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>> Avast logo <https://www.avast.com/antivirus>
>>>>>>>>>
>>>>>>>>> This email has been checked for viruses by Avast antivirus
>>>>>>>>> software.
>>>>>>>>> www.avast.com <https://www.avast.com/antivirus>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /*DISCLAIMER*:
>>>>>>>>> Acest mesaj de posta electronica si documentele aferente sunt
>>>>>>>>> confidentiale. Este interzisa distribuirea, dezvaluirea sau
>>>>>>>>> orice alt mod de utilizare a lor. Daca nu sunteti destinatarul
>>>>>>>>> acestui mesaj, este interzis sa actionati in baza acestor
>>>>>>>>> informatii. Citirea, copierea, distribuirea, dezvaluirea sau
>>>>>>>>> utilizarea in alt mod a informatiei continute in acest mesaj
>>>>>>>>> constituie o incalcare a legii. Daca ati primit mesajul din
>>>>>>>>> greseala, va rugam sa il distrugeti, anuntand expeditorul de
>>>>>>>>> eroarea comisa. Intrucat nu poate fi garantat faptul ca posta
>>>>>>>>> electronica este un mod sigur si lipsit de erori de
>>>>>>>>> transmitere a informatiilor, este responsabilitatea dvs. sa va
>>>>>>>>> asigurati ca mesajul (inclusiv documentele alaturate lui) este
>>>>>>>>> validat si autorizat spre a fi utilizat in mediul dvs./
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>> Avast logo <https://www.avast.com/antivirus>
>>>>>>>
>>>>>>> This email has been checked for viruses by Avast antivirus
>>>>>>> software.
>>>>>>> www.avast.com <https://www.avast.com/antivirus>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> /*DISCLAIMER*:
>>>>>>> Acest mesaj de posta electronica si documentele aferente sunt
>>>>>>> confidentiale. Este interzisa distribuirea, dezvaluirea sau
>>>>>>> orice alt mod de utilizare a lor. Daca nu sunteti destinatarul
>>>>>>> acestui mesaj, este interzis sa actionati in baza acestor
>>>>>>> informatii. Citirea, copierea, distribuirea, dezvaluirea sau
>>>>>>> utilizarea in alt mod a informatiei continute in acest mesaj
>>>>>>> constituie o incalcare a legii. Daca ati primit mesajul din
>>>>>>> greseala, va rugam sa il distrugeti, anuntand expeditorul de
>>>>>>> eroarea comisa. Intrucat nu poate fi garantat faptul ca posta
>>>>>>> electronica este un mod sigur si lipsit de erori de transmitere
>>>>>>> a informatiilor, este responsabilitatea dvs. sa va asigurati ca
>>>>>>> mesajul (inclusiv documentele alaturate lui) este validat si
>>>>>>> autorizat spre a fi utilizat in mediul dvs./
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> Avast logo <https://www.avast.com/antivirus>
>>>>>
>>>>> This email has been checked for viruses by Avast antivirus software.
>>>>> www.avast.com <https://www.avast.com/antivirus>
>>>>>
>>>>>
>>>>>
>>>>> /*DISCLAIMER*:
>>>>> Acest mesaj de posta electronica si documentele aferente sunt
>>>>> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>>>> alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>>>> mesaj, este interzis sa actionati in baza acestor informatii.
>>>>> Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>>>> mod a informatiei continute in acest mesaj constituie o incalcare
>>>>> a legii. Daca ati primit mesajul din greseala, va rugam sa il
>>>>> distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>>>> poate fi garantat faptul ca posta electronica este un mod sigur si
>>>>> lipsit de erori de transmitere a informatiilor, este
>>>>> responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>>>> documentele alaturate lui) este validat si autorizat spre a fi
>>>>> utilizat in mediul dvs./
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>> Avast logo <https://www.avast.com/antivirus>
>>>
>>> This email has been checked for viruses by Avast antivirus software.
>>> www.avast.com <https://www.avast.com/antivirus>
>>>
>>>
>>>
>>> /*DISCLAIMER*:
>>> Acest mesaj de posta electronica si documentele aferente sunt
>>> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>> alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>> mesaj, este interzis sa actionati in baza acestor informatii.
>>> Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>> mod a informatiei continute in acest mesaj constituie o incalcare a
>>> legii. Daca ati primit mesajul din greseala, va rugam sa il
>>> distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>> poate fi garantat faptul ca posta electronica este un mod sigur si
>>> lipsit de erori de transmitere a informatiilor, este
>>> responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>> documentele alaturate lui) este validat si autorizat spre a fi
>>> utilizat in mediul dvs./
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------
> Avast logo <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
>
> /*DISCLAIMER*:
> Acest mesaj de posta electronica si documentele aferente sunt
> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt
> mod de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj,
> este interzis sa actionati in baza acestor informatii. Citirea,
> copierea, distribuirea, dezvaluirea sau utilizarea in alt mod a
> informatiei continute in acest mesaj constituie o incalcare a legii.
> Daca ati primit mesajul din greseala, va rugam sa il distrugeti,
> anuntand expeditorul de eroarea comisa. Intrucat nu poate fi garantat
> faptul ca posta electronica este un mod sigur si lipsit de erori de
> transmitere a informatiilor, este responsabilitatea dvs. sa va
> asigurati ca mesajul (inclusiv documentele alaturate lui) este validat
> si autorizat spre a fi utilizat in mediul dvs./
>
>
Re[2]: [users@httpd] SSL - How client certificates are verified?
Posted by Sterpu Victor <vi...@caido.ro>.
I installed apache 2.4.16 and I have activated SSLOCSPEnable on a
virtual domain but the page is not loading at all with
OCSPEnabled(without OCSP is working).
The error is:
SSL Library Error: error:27069065:OCSP
routines:OCSP_basic_verify:certificate verify error (Verify error:unable
to get local issuer certificate)
AH02039: Certificate Verification: Error (50): application verification
failure
AH01925: failed to verify the OCSP response
I would use SSLOCSPOverrideResponder but I have 4 different OCSP servers
depending on the CA.
I checked the certificates and in the section Authority Information
Access there is a URL to the OCSP server.
This is the information from one of the certificates:
>[1]Authority Info Access
>Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
>Alternative Name:
>URL=http://ocsp.certsign.ro/ocsp
ocsp.digisign.ro is answering on port 80.
Could be a problem with SSLOCSPEnable that is not auto extracting the
OCSP URL?
My configuration is:
SSLEngine on
SSLCertificateFile /etc/ssl/card.casnt.ro/server.crt
SSLCertificateKeyFile /etc/ssl/card.casnt.ro/server.key
SSLCACertificateFile /etc/ssl/certs/RO/All_Certs.pem
SSLVerifyClient require
SSLVerifyDepth 10
SSLOptions +StdEnvVars +ExportCertData
SSLOCSPEnable On
Thank you.
------ Original Message ------
From: "Marat Khalili" <mk...@rqc.ru>
To: users@httpd.apache.org
Sent: 8/23/2015 8:16:06 PM
Subject: Re: [users@httpd] SSL - How client certificates are verified?
>In this case, could you please post the results when you get the
>SSLOCSPEnable fixed? I'm particularly interested in performance.
>-- With Best Regards, Marat Khalili
>On 23/08/2015 19:57, Sterpu Victor wrote:
>>There are 4 CAs, at least 1 uses OCSP(only 1 I called).
>>I hope all of them use OCSP, I don't know the legislation but it seems
>>normal to be required by law.
>>
>>------ Original Message ------
>>From: "Marat Khalili" <mk...@rqc.ru>
>>To: users@httpd.apache.org
>>Sent: 8/23/2015 7:51:14 PM
>>Subject: Re: [users@httpd] SSL - How client certificates are verified?
>>
>>>Oh, I see. In this case you will have to check the status of their
>>>certificates. Still, I suspect all of the tokens are issued by one
>>>CA. Probably it is better to ask this CA for their procedures: do
>>>they use OCSP or just publish CRLs.
>>>-- With Best Regards, Marat Khalili
>>>On 23/08/2015 19:41, Sterpu Victor wrote:
>>>>All clients already have PKCS11 tokens.
>>>>It would be too complicated for them to get used with something
>>>>else.
>>>>
>>>>------ Original Message ------
>>>>From: "Marat Khalili" <mk...@rqc.ru>
>>>>To: users@httpd.apache.org
>>>>Sent: 8/23/2015 7:34:07 PM
>>>>Subject: Re: [users@httpd] SSL - How client certificates are
>>>>verified?
>>>>
>>>>>I see. However, accepting clients certificates from the world
>>>>>recognized authorities is both more expensive (for clients) and
>>>>>more risky than running your own CA (recognized only by your
>>>>>server). If you personally know all your clients it is easier to
>>>>>issue them certificates directly, and revoke them by yourself too
>>>>>if needed.
>>>>>-- With Best Regards, Marat Khalili
>>>>>On 23/08/2015 18:56, Sterpu Victor wrote:
>>>>>>I want to make a page that will authenticate only with PKCS11
>>>>>>tokens.
>>>>>>These tokens contain only certificates from a recognized
>>>>>>authority.
>>>>>>OCSP would be usefull if the token has been declared lost or
>>>>>>stolen.
>>>>>>But I don't want to make things too complicated.
>>>>>>
>>>>>>
>>>>>>------ Original Message ------
>>>>>>From: "Marat Khalili" <mk...@rqc.ru>
>>>>>>To: users@httpd.apache.org
>>>>>>Sent: 8/23/2015 6:51:02 PM
>>>>>>Subject: Re: [users@httpd] SSL - How client certificates are
>>>>>>verified?
>>>>>>
>>>>>>>Hello, what is your scenario? If you issue (sign) client
>>>>>>>certificates yourself, Apache can correctly verify it against
>>>>>>>local CRL (certificate revocation list) file (server restart may
>>>>>>>be required after file update). There's information in the net
>>>>>>>concerning OCSP support for client authentication in newer
>>>>>>>versions of Apache (google SSLOCSPEnable), but I can see no real
>>>>>>>use for it save for some very complicated systems.
>>>>>>>-- With Best Regards, Marat Khalili
>>>>>>>On 23/08/2015 09:51, Sterpu Victor wrote:
>>>>>>>>Hello
>>>>>>>>
>>>>>>>>I have a web page that asks for client certificate.
>>>>>>>>These are the options for this:
>>>>>>>>
>>>>>>>>SSLVerifyClient require
>>>>>>>>SSLVerifyDepth 10
>>>>>>>>
>>>>>>>>How does SSLVerifyClient verifies the client certificate?
>>>>>>>>This option protects against certificates manual made with a
>>>>>>>>fake public-private key pair?
>>>>>>>>So can someoane make a certificate identical with the original,
>>>>>>>>attach another set of public and private keys and pretend to be
>>>>>>>>someoane else?
>>>>>>>>
>>>>>>>>Thank you
>>>>>>>>
>>>>>>>>
>>>>>>>>--------------------------------------------------------------------------------
>>>>>>>>This email has been checked for viruses by Avast antivirus
>>>>>>>>software.
>>>>>>>>www.avast.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>DISCLAIMER:
>>>>>>>>Acest mesaj de posta electronica si documentele aferente sunt
>>>>>>>>confidentiale. Este interzisa distribuirea, dezvaluirea sau
>>>>>>>>orice alt mod de utilizare a lor. Daca nu sunteti destinatarul
>>>>>>>>acestui mesaj, este interzis sa actionati in baza acestor
>>>>>>>>informatii. Citirea, copierea, distribuirea, dezvaluirea sau
>>>>>>>>utilizarea in alt mod a informatiei continute in acest mesaj
>>>>>>>>constituie o incalcare a legii. Daca ati primit mesajul din
>>>>>>>>greseala, va rugam sa il distrugeti, anuntand expeditorul de
>>>>>>>>eroarea comisa. Intrucat nu poate fi garantat faptul ca posta
>>>>>>>>electronica este un mod sigur si lipsit de erori de transmitere
>>>>>>>>a informatiilor, este responsabilitatea dvs. sa va asigurati ca
>>>>>>>>mesajul (inclusiv documentele alaturate lui) este validat si
>>>>>>>>autorizat spre a fi utilizat in mediul dvs.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>--------------------------------------------------------------------------------
>>>>>>This email has been checked for viruses by Avast antivirus
>>>>>>software.
>>>>>>www.avast.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>DISCLAIMER:
>>>>>>Acest mesaj de posta electronica si documentele aferente sunt
>>>>>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>>>>>alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>>>>>mesaj, este interzis sa actionati in baza acestor informatii.
>>>>>>Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>>>>>mod a informatiei continute in acest mesaj constituie o incalcare
>>>>>>a legii. Daca ati primit mesajul din greseala, va rugam sa il
>>>>>>distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>>>>>poate fi garantat faptul ca posta electronica este un mod sigur si
>>>>>>lipsit de erori de transmitere a informatiilor, este
>>>>>>responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>>>>>documentele alaturate lui) este validat si autorizat spre a fi
>>>>>>utilizat in mediul dvs.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>--------------------------------------------------------------------------------
>>>>This email has been checked for viruses by Avast antivirus software.
>>>>www.avast.com
>>>>
>>>>
>>>>
>>>>DISCLAIMER:
>>>>Acest mesaj de posta electronica si documentele aferente sunt
>>>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>>>alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>>>mesaj, este interzis sa actionati in baza acestor informatii.
>>>>Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>>>mod a informatiei continute in acest mesaj constituie o incalcare a
>>>>legii. Daca ati primit mesajul din greseala, va rugam sa il
>>>>distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>>>poate fi garantat faptul ca posta electronica este un mod sigur si
>>>>lipsit de erori de transmitere a informatiilor, este
>>>>responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>>>documentele alaturate lui) este validat si autorizat spre a fi
>>>>utilizat in mediul dvs.
>>>>
>>>>
>>>
>>
>>
>>--------------------------------------------------------------------------------
>>This email has been checked for viruses by Avast antivirus software.
>>www.avast.com
>>
>>
>>
>>DISCLAIMER:
>>Acest mesaj de posta electronica si documentele aferente sunt
>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt
>>mod de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj,
>>este interzis sa actionati in baza acestor informatii. Citirea,
>>copierea, distribuirea, dezvaluirea sau utilizarea in alt mod a
>>informatiei continute in acest mesaj constituie o incalcare a legii.
>>Daca ati primit mesajul din greseala, va rugam sa il distrugeti,
>>anuntand expeditorul de eroarea comisa. Intrucat nu poate fi garantat
>>faptul ca posta electronica este un mod sigur si lipsit de erori de
>>transmitere a informatiilor, este responsabilitatea dvs. sa va
>>asigurati ca mesajul (inclusiv documentele alaturate lui) este validat
>>si autorizat spre a fi utilizat in mediul dvs.
>>
>>
>
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: [users@httpd] SSL - How client certificates are verified?
Posted by Marat Khalili <mk...@rqc.ru>.
In this case, could you please post the results when you get the
SSLOCSPEnable fixed? I'm particularly interested in performance.
--
With Best Regards,
Marat Khalili
On 23/08/2015 19:57, Sterpu Victor wrote:
> There are 4 CAs, at least 1 uses OCSP(only 1 I called).
> I hope all of them use OCSP, I don't know the legislation but it seems
> normal to be required by law.
> ------ Original Message ------
> From: "Marat Khalili" <mkh@rqc.ru <ma...@rqc.ru>>
> To: users@httpd.apache.org <ma...@httpd.apache.org>
> Sent: 8/23/2015 7:51:14 PM
> Subject: Re: [users@httpd] SSL - How client certificates are verified?
>> Oh, I see. In this case you will have to check the status of their
>> certificates. Still, I suspect all of the tokens are issued by one
>> CA. Probably it is better to ask this CA for their procedures: do
>> they use OCSP or just publish CRLs.
>> --
>>
>> With Best Regards,
>> Marat Khalili
>>
>> On 23/08/2015 19:41, Sterpu Victor wrote:
>>> All clients already have PKCS11 tokens.
>>> It would be too complicated for them to get used with something else.
>>> ------ Original Message ------
>>> From: "Marat Khalili" <mkh@rqc.ru <ma...@rqc.ru>>
>>> To: users@httpd.apache.org <ma...@httpd.apache.org>
>>> Sent: 8/23/2015 7:34:07 PM
>>> Subject: Re: [users@httpd] SSL - How client certificates are verified?
>>>> I see. However, accepting clients certificates from the world
>>>> recognized authorities is both more expensive (for clients) and
>>>> more risky than running your own CA (recognized only by your
>>>> server). If you personally know all your clients it is easier to
>>>> issue them certificates directly, and revoke them by yourself too
>>>> if needed.
>>>> --
>>>>
>>>> With Best Regards,
>>>> Marat Khalili
>>>>
>>>> On 23/08/2015 18:56, Sterpu Victor wrote:
>>>>> I want to make a page that will authenticate only with PKCS11 tokens.
>>>>> These tokens contain only certificates from a recognized authority.
>>>>> OCSP would be usefull if the token has been declared lost or stolen.
>>>>> But I don't want to make things too complicated.
>>>>> ------ Original Message ------
>>>>> From: "Marat Khalili" <mkh@rqc.ru <ma...@rqc.ru>>
>>>>> To: users@httpd.apache.org <ma...@httpd.apache.org>
>>>>> Sent: 8/23/2015 6:51:02 PM
>>>>> Subject: Re: [users@httpd] SSL - How client certificates are verified?
>>>>>> Hello, what is your scenario? If you issue (sign) client
>>>>>> certificates yourself, Apache can correctly verify it against
>>>>>> local CRL (certificate revocation list) file (server restart may
>>>>>> be required after file update). There's information in the net
>>>>>> concerning OCSP support for client authentication in newer
>>>>>> versions of Apache (google SSLOCSPEnable), but I can see no real
>>>>>> use for it save for some very complicated systems.
>>>>>> --
>>>>>>
>>>>>> With Best Regards,
>>>>>> Marat Khalili
>>>>>>
>>>>>> On 23/08/2015 09:51, Sterpu Victor wrote:
>>>>>>> Hello
>>>>>>> I have a web page that asks for client certificate.
>>>>>>> These are the options for this:
>>>>>>> SSLVerifyClient require
>>>>>>> SSLVerifyDepth 10
>>>>>>>
>>>>>>> How does SSLVerifyClient verifies the client certificate?
>>>>>>> This option protects against certificates manual made with a
>>>>>>> fake public-private key pair?
>>>>>>> So can someoane make a certificate identical with the original,
>>>>>>> attach another set of public and private keys and pretend to be
>>>>>>> someoane else?
>>>>>>> Thank you
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>> Avast logo <https://www.avast.com/antivirus>
>>>>>>>
>>>>>>> This email has been checked for viruses by Avast antivirus
>>>>>>> software.
>>>>>>> www.avast.com <https://www.avast.com/antivirus>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> /*DISCLAIMER*:
>>>>>>> Acest mesaj de posta electronica si documentele aferente sunt
>>>>>>> confidentiale. Este interzisa distribuirea, dezvaluirea sau
>>>>>>> orice alt mod de utilizare a lor. Daca nu sunteti destinatarul
>>>>>>> acestui mesaj, este interzis sa actionati in baza acestor
>>>>>>> informatii. Citirea, copierea, distribuirea, dezvaluirea sau
>>>>>>> utilizarea in alt mod a informatiei continute in acest mesaj
>>>>>>> constituie o incalcare a legii. Daca ati primit mesajul din
>>>>>>> greseala, va rugam sa il distrugeti, anuntand expeditorul de
>>>>>>> eroarea comisa. Intrucat nu poate fi garantat faptul ca posta
>>>>>>> electronica este un mod sigur si lipsit de erori de transmitere
>>>>>>> a informatiilor, este responsabilitatea dvs. sa va asigurati ca
>>>>>>> mesajul (inclusiv documentele alaturate lui) este validat si
>>>>>>> autorizat spre a fi utilizat in mediul dvs./
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> Avast logo <https://www.avast.com/antivirus>
>>>>>
>>>>> This email has been checked for viruses by Avast antivirus software.
>>>>> www.avast.com <https://www.avast.com/antivirus>
>>>>>
>>>>>
>>>>>
>>>>> /*DISCLAIMER*:
>>>>> Acest mesaj de posta electronica si documentele aferente sunt
>>>>> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>>>> alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>>>> mesaj, este interzis sa actionati in baza acestor informatii.
>>>>> Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>>>> mod a informatiei continute in acest mesaj constituie o incalcare
>>>>> a legii. Daca ati primit mesajul din greseala, va rugam sa il
>>>>> distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>>>> poate fi garantat faptul ca posta electronica este un mod sigur si
>>>>> lipsit de erori de transmitere a informatiilor, este
>>>>> responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>>>> documentele alaturate lui) este validat si autorizat spre a fi
>>>>> utilizat in mediul dvs./
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>> Avast logo <https://www.avast.com/antivirus>
>>>
>>> This email has been checked for viruses by Avast antivirus software.
>>> www.avast.com <https://www.avast.com/antivirus>
>>>
>>>
>>>
>>> /*DISCLAIMER*:
>>> Acest mesaj de posta electronica si documentele aferente sunt
>>> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>> alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>> mesaj, este interzis sa actionati in baza acestor informatii.
>>> Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>> mod a informatiei continute in acest mesaj constituie o incalcare a
>>> legii. Daca ati primit mesajul din greseala, va rugam sa il
>>> distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>> poate fi garantat faptul ca posta electronica este un mod sigur si
>>> lipsit de erori de transmitere a informatiilor, este
>>> responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>> documentele alaturate lui) este validat si autorizat spre a fi
>>> utilizat in mediul dvs./
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------
> Avast logo <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
>
> /*DISCLAIMER*:
> Acest mesaj de posta electronica si documentele aferente sunt
> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt
> mod de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj,
> este interzis sa actionati in baza acestor informatii. Citirea,
> copierea, distribuirea, dezvaluirea sau utilizarea in alt mod a
> informatiei continute in acest mesaj constituie o incalcare a legii.
> Daca ati primit mesajul din greseala, va rugam sa il distrugeti,
> anuntand expeditorul de eroarea comisa. Intrucat nu poate fi garantat
> faptul ca posta electronica este un mod sigur si lipsit de erori de
> transmitere a informatiilor, este responsabilitatea dvs. sa va
> asigurati ca mesajul (inclusiv documentele alaturate lui) este validat
> si autorizat spre a fi utilizat in mediul dvs./
>
>
Re[2]: [users@httpd] SSL - How client certificates are verified?
Posted by Sterpu Victor <vi...@caido.ro>.
There are 4 CAs, at least 1 uses OCSP(only 1 I called).
I hope all of them use OCSP, I don't know the legislation but it seems
normal to be required by law.
------ Original Message ------
From: "Marat Khalili" <mk...@rqc.ru>
To: users@httpd.apache.org
Sent: 8/23/2015 7:51:14 PM
Subject: Re: [users@httpd] SSL - How client certificates are verified?
>Oh, I see. In this case you will have to check the status of their
>certificates. Still, I suspect all of the tokens are issued by one CA.
>Probably it is better to ask this CA for their procedures: do they use
>OCSP or just publish CRLs.
>-- With Best Regards, Marat Khalili
>On 23/08/2015 19:41, Sterpu Victor wrote:
>>All clients already have PKCS11 tokens.
>>It would be too complicated for them to get used with something else.
>>
>>------ Original Message ------
>>From: "Marat Khalili" <mk...@rqc.ru>
>>To: users@httpd.apache.org
>>Sent: 8/23/2015 7:34:07 PM
>>Subject: Re: [users@httpd] SSL - How client certificates are verified?
>>
>>>I see. However, accepting clients certificates from the world
>>>recognized authorities is both more expensive (for clients) and more
>>>risky than running your own CA (recognized only by your server). If
>>>you personally know all your clients it is easier to issue them
>>>certificates directly, and revoke them by yourself too if needed.
>>>-- With Best Regards, Marat Khalili
>>>On 23/08/2015 18:56, Sterpu Victor wrote:
>>>>I want to make a page that will authenticate only with PKCS11
>>>>tokens.
>>>>These tokens contain only certificates from a recognized authority.
>>>>OCSP would be usefull if the token has been declared lost or stolen.
>>>>But I don't want to make things too complicated.
>>>>
>>>>
>>>>------ Original Message ------
>>>>From: "Marat Khalili" <mk...@rqc.ru>
>>>>To: users@httpd.apache.org
>>>>Sent: 8/23/2015 6:51:02 PM
>>>>Subject: Re: [users@httpd] SSL - How client certificates are
>>>>verified?
>>>>
>>>>>Hello, what is your scenario? If you issue (sign) client
>>>>>certificates yourself, Apache can correctly verify it against local
>>>>>CRL (certificate revocation list) file (server restart may be
>>>>>required after file update). There's information in the net
>>>>>concerning OCSP support for client authentication in newer versions
>>>>>of Apache (google SSLOCSPEnable), but I can see no real use for it
>>>>>save for some very complicated systems.
>>>>>-- With Best Regards, Marat Khalili
>>>>>On 23/08/2015 09:51, Sterpu Victor wrote:
>>>>>>Hello
>>>>>>
>>>>>>I have a web page that asks for client certificate.
>>>>>>These are the options for this:
>>>>>>
>>>>>>SSLVerifyClient require
>>>>>>SSLVerifyDepth 10
>>>>>>
>>>>>>How does SSLVerifyClient verifies the client certificate?
>>>>>>This option protects against certificates manual made with a fake
>>>>>>public-private key pair?
>>>>>>So can someoane make a certificate identical with the original,
>>>>>>attach another set of public and private keys and pretend to be
>>>>>>someoane else?
>>>>>>
>>>>>>Thank you
>>>>>>
>>>>>>
>>>>>>--------------------------------------------------------------------------------
>>>>>>This email has been checked for viruses by Avast antivirus
>>>>>>software.
>>>>>>www.avast.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>DISCLAIMER:
>>>>>>Acest mesaj de posta electronica si documentele aferente sunt
>>>>>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>>>>>alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>>>>>mesaj, este interzis sa actionati in baza acestor informatii.
>>>>>>Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>>>>>mod a informatiei continute in acest mesaj constituie o incalcare
>>>>>>a legii. Daca ati primit mesajul din greseala, va rugam sa il
>>>>>>distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>>>>>poate fi garantat faptul ca posta electronica este un mod sigur si
>>>>>>lipsit de erori de transmitere a informatiilor, este
>>>>>>responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>>>>>documentele alaturate lui) este validat si autorizat spre a fi
>>>>>>utilizat in mediul dvs.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>--------------------------------------------------------------------------------
>>>>This email has been checked for viruses by Avast antivirus software.
>>>>www.avast.com
>>>>
>>>>
>>>>
>>>>DISCLAIMER:
>>>>Acest mesaj de posta electronica si documentele aferente sunt
>>>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>>>alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>>>mesaj, este interzis sa actionati in baza acestor informatii.
>>>>Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>>>mod a informatiei continute in acest mesaj constituie o incalcare a
>>>>legii. Daca ati primit mesajul din greseala, va rugam sa il
>>>>distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>>>poate fi garantat faptul ca posta electronica este un mod sigur si
>>>>lipsit de erori de transmitere a informatiilor, este
>>>>responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>>>documentele alaturate lui) este validat si autorizat spre a fi
>>>>utilizat in mediul dvs.
>>>>
>>>>
>>>
>>
>>
>>--------------------------------------------------------------------------------
>>This email has been checked for viruses by Avast antivirus software.
>>www.avast.com
>>
>>
>>
>>DISCLAIMER:
>>Acest mesaj de posta electronica si documentele aferente sunt
>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt
>>mod de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj,
>>este interzis sa actionati in baza acestor informatii. Citirea,
>>copierea, distribuirea, dezvaluirea sau utilizarea in alt mod a
>>informatiei continute in acest mesaj constituie o incalcare a legii.
>>Daca ati primit mesajul din greseala, va rugam sa il distrugeti,
>>anuntand expeditorul de eroarea comisa. Intrucat nu poate fi garantat
>>faptul ca posta electronica este un mod sigur si lipsit de erori de
>>transmitere a informatiilor, este responsabilitatea dvs. sa va
>>asigurati ca mesajul (inclusiv documentele alaturate lui) este validat
>>si autorizat spre a fi utilizat in mediul dvs.
>>
>>
>
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: [users@httpd] SSL - How client certificates are verified?
Posted by Marat Khalili <mk...@rqc.ru>.
Oh, I see. In this case you will have to check the status of their
certificates. Still, I suspect all of the tokens are issued by one CA.
Probably it is better to ask this CA for their procedures: do they use
OCSP or just publish CRLs.
--
With Best Regards,
Marat Khalili
On 23/08/2015 19:41, Sterpu Victor wrote:
> All clients already have PKCS11 tokens.
> It would be too complicated for them to get used with something else.
> ------ Original Message ------
> From: "Marat Khalili" <mkh@rqc.ru <ma...@rqc.ru>>
> To: users@httpd.apache.org <ma...@httpd.apache.org>
> Sent: 8/23/2015 7:34:07 PM
> Subject: Re: [users@httpd] SSL - How client certificates are verified?
>> I see. However, accepting clients certificates from the world
>> recognized authorities is both more expensive (for clients) and more
>> risky than running your own CA (recognized only by your server). If
>> you personally know all your clients it is easier to issue them
>> certificates directly, and revoke them by yourself too if needed.
>> --
>>
>> With Best Regards,
>> Marat Khalili
>>
>> On 23/08/2015 18:56, Sterpu Victor wrote:
>>> I want to make a page that will authenticate only with PKCS11 tokens.
>>> These tokens contain only certificates from a recognized authority.
>>> OCSP would be usefull if the token has been declared lost or stolen.
>>> But I don't want to make things too complicated.
>>> ------ Original Message ------
>>> From: "Marat Khalili" <mkh@rqc.ru <ma...@rqc.ru>>
>>> To: users@httpd.apache.org <ma...@httpd.apache.org>
>>> Sent: 8/23/2015 6:51:02 PM
>>> Subject: Re: [users@httpd] SSL - How client certificates are verified?
>>>> Hello, what is your scenario? If you issue (sign) client
>>>> certificates yourself, Apache can correctly verify it against local
>>>> CRL (certificate revocation list) file (server restart may be
>>>> required after file update). There's information in the net
>>>> concerning OCSP support for client authentication in newer versions
>>>> of Apache (google SSLOCSPEnable), but I can see no real use for it
>>>> save for some very complicated systems.
>>>> --
>>>>
>>>> With Best Regards,
>>>> Marat Khalili
>>>>
>>>> On 23/08/2015 09:51, Sterpu Victor wrote:
>>>>> Hello
>>>>> I have a web page that asks for client certificate.
>>>>> These are the options for this:
>>>>> SSLVerifyClient require
>>>>> SSLVerifyDepth 10
>>>>>
>>>>> How does SSLVerifyClient verifies the client certificate?
>>>>> This option protects against certificates manual made with a fake
>>>>> public-private key pair?
>>>>> So can someoane make a certificate identical with the original,
>>>>> attach another set of public and private keys and pretend to be
>>>>> someoane else?
>>>>> Thank you
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> Avast logo <https://www.avast.com/antivirus>
>>>>>
>>>>> This email has been checked for viruses by Avast antivirus software.
>>>>> www.avast.com <https://www.avast.com/antivirus>
>>>>>
>>>>>
>>>>>
>>>>> /*DISCLAIMER*:
>>>>> Acest mesaj de posta electronica si documentele aferente sunt
>>>>> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>>>> alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>>>> mesaj, este interzis sa actionati in baza acestor informatii.
>>>>> Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>>>> mod a informatiei continute in acest mesaj constituie o incalcare
>>>>> a legii. Daca ati primit mesajul din greseala, va rugam sa il
>>>>> distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>>>> poate fi garantat faptul ca posta electronica este un mod sigur si
>>>>> lipsit de erori de transmitere a informatiilor, este
>>>>> responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>>>> documentele alaturate lui) este validat si autorizat spre a fi
>>>>> utilizat in mediul dvs./
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>> Avast logo <https://www.avast.com/antivirus>
>>>
>>> This email has been checked for viruses by Avast antivirus software.
>>> www.avast.com <https://www.avast.com/antivirus>
>>>
>>>
>>>
>>> /*DISCLAIMER*:
>>> Acest mesaj de posta electronica si documentele aferente sunt
>>> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>> alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>> mesaj, este interzis sa actionati in baza acestor informatii.
>>> Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>> mod a informatiei continute in acest mesaj constituie o incalcare a
>>> legii. Daca ati primit mesajul din greseala, va rugam sa il
>>> distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>> poate fi garantat faptul ca posta electronica este un mod sigur si
>>> lipsit de erori de transmitere a informatiilor, este
>>> responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>> documentele alaturate lui) este validat si autorizat spre a fi
>>> utilizat in mediul dvs./
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------
> Avast logo <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
>
> /*DISCLAIMER*:
> Acest mesaj de posta electronica si documentele aferente sunt
> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt
> mod de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj,
> este interzis sa actionati in baza acestor informatii. Citirea,
> copierea, distribuirea, dezvaluirea sau utilizarea in alt mod a
> informatiei continute in acest mesaj constituie o incalcare a legii.
> Daca ati primit mesajul din greseala, va rugam sa il distrugeti,
> anuntand expeditorul de eroarea comisa. Intrucat nu poate fi garantat
> faptul ca posta electronica este un mod sigur si lipsit de erori de
> transmitere a informatiilor, este responsabilitatea dvs. sa va
> asigurati ca mesajul (inclusiv documentele alaturate lui) este validat
> si autorizat spre a fi utilizat in mediul dvs./
>
>
Re[2]: [users@httpd] SSL - How client certificates are verified?
Posted by Sterpu Victor <vi...@caido.ro>.
All clients already have PKCS11 tokens.
It would be too complicated for them to get used with something else.
------ Original Message ------
From: "Marat Khalili" <mk...@rqc.ru>
To: users@httpd.apache.org
Sent: 8/23/2015 7:34:07 PM
Subject: Re: [users@httpd] SSL - How client certificates are verified?
>I see. However, accepting clients certificates from the world
>recognized authorities is both more expensive (for clients) and more
>risky than running your own CA (recognized only by your server). If you
>personally know all your clients it is easier to issue them
>certificates directly, and revoke them by yourself too if needed.
>-- With Best Regards, Marat Khalili
>On 23/08/2015 18:56, Sterpu Victor wrote:
>>I want to make a page that will authenticate only with PKCS11 tokens.
>>These tokens contain only certificates from a recognized authority.
>>OCSP would be usefull if the token has been declared lost or stolen.
>>But I don't want to make things too complicated.
>>
>>
>>------ Original Message ------
>>From: "Marat Khalili" <mk...@rqc.ru>
>>To: users@httpd.apache.org
>>Sent: 8/23/2015 6:51:02 PM
>>Subject: Re: [users@httpd] SSL - How client certificates are verified?
>>
>>>Hello, what is your scenario? If you issue (sign) client certificates
>>>yourself, Apache can correctly verify it against local CRL
>>>(certificate revocation list) file (server restart may be required
>>>after file update). There's information in the net concerning OCSP
>>>support for client authentication in newer versions of Apache (google
>>>SSLOCSPEnable), but I can see no real use for it save for some very
>>>complicated systems.
>>>-- With Best Regards, Marat Khalili
>>>On 23/08/2015 09:51, Sterpu Victor wrote:
>>>>Hello
>>>>
>>>>I have a web page that asks for client certificate.
>>>>These are the options for this:
>>>>
>>>>SSLVerifyClient require
>>>>SSLVerifyDepth 10
>>>>
>>>>How does SSLVerifyClient verifies the client certificate?
>>>>This option protects against certificates manual made with a fake
>>>>public-private key pair?
>>>>So can someoane make a certificate identical with the original,
>>>>attach another set of public and private keys and pretend to be
>>>>someoane else?
>>>>
>>>>Thank you
>>>>
>>>>
>>>>--------------------------------------------------------------------------------
>>>>This email has been checked for viruses by Avast antivirus software.
>>>>www.avast.com
>>>>
>>>>
>>>>
>>>>DISCLAIMER:
>>>>Acest mesaj de posta electronica si documentele aferente sunt
>>>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>>>alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>>>mesaj, este interzis sa actionati in baza acestor informatii.
>>>>Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>>>mod a informatiei continute in acest mesaj constituie o incalcare a
>>>>legii. Daca ati primit mesajul din greseala, va rugam sa il
>>>>distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>>>poate fi garantat faptul ca posta electronica este un mod sigur si
>>>>lipsit de erori de transmitere a informatiilor, este
>>>>responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>>>documentele alaturate lui) este validat si autorizat spre a fi
>>>>utilizat in mediul dvs.
>>>>
>>>>
>>>
>>
>>
>>--------------------------------------------------------------------------------
>>This email has been checked for viruses by Avast antivirus software.
>>www.avast.com
>>
>>
>>
>>DISCLAIMER:
>>Acest mesaj de posta electronica si documentele aferente sunt
>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt
>>mod de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj,
>>este interzis sa actionati in baza acestor informatii. Citirea,
>>copierea, distribuirea, dezvaluirea sau utilizarea in alt mod a
>>informatiei continute in acest mesaj constituie o incalcare a legii.
>>Daca ati primit mesajul din greseala, va rugam sa il distrugeti,
>>anuntand expeditorul de eroarea comisa. Intrucat nu poate fi garantat
>>faptul ca posta electronica este un mod sigur si lipsit de erori de
>>transmitere a informatiilor, este responsabilitatea dvs. sa va
>>asigurati ca mesajul (inclusiv documentele alaturate lui) este validat
>>si autorizat spre a fi utilizat in mediul dvs.
>>
>>
>
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: [users@httpd] SSL - How client certificates are verified?
Posted by Marat Khalili <mk...@rqc.ru>.
I see. However, accepting clients certificates from the world recognized
authorities is both more expensive (for clients) and more risky than
running your own CA (recognized only by your server). If you personally
know all your clients it is easier to issue them certificates directly,
and revoke them by yourself too if needed.
--
With Best Regards,
Marat Khalili
On 23/08/2015 18:56, Sterpu Victor wrote:
> I want to make a page that will authenticate only with PKCS11 tokens.
> These tokens contain only certificates from a recognized authority.
> OCSP would be usefull if the token has been declared lost or stolen.
> But I don't want to make things too complicated.
> ------ Original Message ------
> From: "Marat Khalili" <mkh@rqc.ru <ma...@rqc.ru>>
> To: users@httpd.apache.org <ma...@httpd.apache.org>
> Sent: 8/23/2015 6:51:02 PM
> Subject: Re: [users@httpd] SSL - How client certificates are verified?
>> Hello, what is your scenario? If you issue (sign) client certificates
>> yourself, Apache can correctly verify it against local CRL
>> (certificate revocation list) file (server restart may be required
>> after file update). There's information in the net concerning OCSP
>> support for client authentication in newer versions of Apache (google
>> SSLOCSPEnable), but I can see no real use for it save for some very
>> complicated systems.
>> --
>>
>> With Best Regards,
>> Marat Khalili
>>
>> On 23/08/2015 09:51, Sterpu Victor wrote:
>>> Hello
>>> I have a web page that asks for client certificate.
>>> These are the options for this:
>>> SSLVerifyClient require
>>> SSLVerifyDepth 10
>>>
>>> How does SSLVerifyClient verifies the client certificate?
>>> This option protects against certificates manual made with a fake
>>> public-private key pair?
>>> So can someoane make a certificate identical with the original,
>>> attach another set of public and private keys and pretend to be
>>> someoane else?
>>> Thank you
>>>
>>>
>>> ------------------------------------------------------------------------
>>> Avast logo <https://www.avast.com/antivirus>
>>>
>>> This email has been checked for viruses by Avast antivirus software.
>>> www.avast.com <https://www.avast.com/antivirus>
>>>
>>>
>>>
>>> /*DISCLAIMER*:
>>> Acest mesaj de posta electronica si documentele aferente sunt
>>> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice
>>> alt mod de utilizare a lor. Daca nu sunteti destinatarul acestui
>>> mesaj, este interzis sa actionati in baza acestor informatii.
>>> Citirea, copierea, distribuirea, dezvaluirea sau utilizarea in alt
>>> mod a informatiei continute in acest mesaj constituie o incalcare a
>>> legii. Daca ati primit mesajul din greseala, va rugam sa il
>>> distrugeti, anuntand expeditorul de eroarea comisa. Intrucat nu
>>> poate fi garantat faptul ca posta electronica este un mod sigur si
>>> lipsit de erori de transmitere a informatiilor, este
>>> responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv
>>> documentele alaturate lui) este validat si autorizat spre a fi
>>> utilizat in mediul dvs./
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------
> Avast logo <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
>
> /*DISCLAIMER*:
> Acest mesaj de posta electronica si documentele aferente sunt
> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt
> mod de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj,
> este interzis sa actionati in baza acestor informatii. Citirea,
> copierea, distribuirea, dezvaluirea sau utilizarea in alt mod a
> informatiei continute in acest mesaj constituie o incalcare a legii.
> Daca ati primit mesajul din greseala, va rugam sa il distrugeti,
> anuntand expeditorul de eroarea comisa. Intrucat nu poate fi garantat
> faptul ca posta electronica este un mod sigur si lipsit de erori de
> transmitere a informatiilor, este responsabilitatea dvs. sa va
> asigurati ca mesajul (inclusiv documentele alaturate lui) este validat
> si autorizat spre a fi utilizat in mediul dvs./
>
>
Re[2]: [users@httpd] SSL - How client certificates are verified?
Posted by Sterpu Victor <vi...@caido.ro>.
I want to make a page that will authenticate only with PKCS11 tokens.
These tokens contain only certificates from a recognized authority.
OCSP would be usefull if the token has been declared lost or stolen.
But I don't want to make things too complicated.
------ Original Message ------
From: "Marat Khalili" <mk...@rqc.ru>
To: users@httpd.apache.org
Sent: 8/23/2015 6:51:02 PM
Subject: Re: [users@httpd] SSL - How client certificates are verified?
>Hello, what is your scenario? If you issue (sign) client certificates
>yourself, Apache can correctly verify it against local CRL (certificate
>revocation list) file (server restart may be required after file
>update). There's information in the net concerning OCSP support for
>client authentication in newer versions of Apache (google
>SSLOCSPEnable), but I can see no real use for it save for some very
>complicated systems.
>-- With Best Regards, Marat Khalili
>On 23/08/2015 09:51, Sterpu Victor wrote:
>>Hello
>>
>>I have a web page that asks for client certificate.
>>These are the options for this:
>>
>>SSLVerifyClient require
>>SSLVerifyDepth 10
>>
>>How does SSLVerifyClient verifies the client certificate?
>>This option protects against certificates manual made with a fake
>>public-private key pair?
>>So can someoane make a certificate identical with the original, attach
>>another set of public and private keys and pretend to be someoane
>>else?
>>
>>Thank you
>>
>>
>>--------------------------------------------------------------------------------
>>This email has been checked for viruses by Avast antivirus software.
>>www.avast.com
>>
>>
>>
>>DISCLAIMER:
>>Acest mesaj de posta electronica si documentele aferente sunt
>>confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt
>>mod de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj,
>>este interzis sa actionati in baza acestor informatii. Citirea,
>>copierea, distribuirea, dezvaluirea sau utilizarea in alt mod a
>>informatiei continute in acest mesaj constituie o incalcare a legii.
>>Daca ati primit mesajul din greseala, va rugam sa il distrugeti,
>>anuntand expeditorul de eroarea comisa. Intrucat nu poate fi garantat
>>faptul ca posta electronica este un mod sigur si lipsit de erori de
>>transmitere a informatiilor, este responsabilitatea dvs. sa va
>>asigurati ca mesajul (inclusiv documentele alaturate lui) este validat
>>si autorizat spre a fi utilizat in mediul dvs.
>>
>>
>
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: [users@httpd] SSL - How client certificates are verified?
Posted by Marat Khalili <mk...@rqc.ru>.
Hello, what is your scenario? If you issue (sign) client certificates
yourself, Apache can correctly verify it against local CRL (certificate
revocation list) file (server restart may be required after file
update). There's information in the net concerning OCSP support for
client authentication in newer versions of Apache (google
SSLOCSPEnable), but I can see no real use for it save for some very
complicated systems.
--
With Best Regards,
Marat Khalili
On 23/08/2015 09:51, Sterpu Victor wrote:
> Hello
> I have a web page that asks for client certificate.
> These are the options for this:
> SSLVerifyClient require
> SSLVerifyDepth 10
>
> How does SSLVerifyClient verifies the client certificate?
> This option protects against certificates manual made with a fake
> public-private key pair?
> So can someoane make a certificate identical with the original, attach
> another set of public and private keys and pretend to be someoane else?
> Thank you
>
>
> ------------------------------------------------------------------------
> Avast logo <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
>
> /*DISCLAIMER*:
> Acest mesaj de posta electronica si documentele aferente sunt
> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt
> mod de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj,
> este interzis sa actionati in baza acestor informatii. Citirea,
> copierea, distribuirea, dezvaluirea sau utilizarea in alt mod a
> informatiei continute in acest mesaj constituie o incalcare a legii.
> Daca ati primit mesajul din greseala, va rugam sa il distrugeti,
> anuntand expeditorul de eroarea comisa. Intrucat nu poate fi garantat
> faptul ca posta electronica este un mod sigur si lipsit de erori de
> transmitere a informatiilor, este responsabilitatea dvs. sa va
> asigurati ca mesajul (inclusiv documentele alaturate lui) este validat
> si autorizat spre a fi utilizat in mediul dvs./
>
>
Re: Re[2]: [users@httpd] SSL - How client certificates are verified?
Posted by Mohanavelu Subramanian <mh...@gmail.com>.
yes you are right about client certificate verification with CA.
i am not sure about OCSP verification.
On Sun, Aug 23, 2015 at 1:21 PM, Sterpu Victor <vi...@caido.ro> wrote:
> I'm not sure I got this right, this is what I was thinking:
> - client sends his certificate, with the public key included; the
> certificate contains a signature of the client certificate made with the
> private key of the CA;
> - apache server has the public key of the CA and can check the signature
> of the CA
> Is this right?
>
> Does this check includes OCSP verification? If not can this be done from
> apache?
>
> Thank you.
>
> ------ Original Message ------
> From: "Mohanavelu Subramanian" <mh...@gmail.com>
> To: users@httpd.apache.org; "Sterpu Victor" <vi...@caido.ro>
> Sent: 8/23/2015 10:19:13 AM
> Subject: Re: [users@httpd] SSL - How client certificates are verified?
>
>
> Hi,
>
> With the option "SSLVerifyClient require" , server mandates the client to
> send its certificate for authentication. Then the server verifies this
> client certificate against the CA certificate file configured in apache. If
> the client certificate has been signed by a valid CA, then the
> authentication is successful.
>
> There are cases where sub CA certificate can be generated from root
> certificate. So, this will end up in a hierarchy of CA certificates. The
> final sub CA certificate would be used to sign client certificate. With
> option "SSLVerifyDepth 10", the server will verify the client certificate
> to the level of 10, meaning it will verify from 0 to up the hierarchy 10.
> Maximum depth of CA Certificates in Client Certificate verification
>
> When the client sends its fake certificate(not signed by the CA) , the
> authentication will fail at server.
>
> Regards,
> Mohan
>
> On Sun, Aug 23, 2015 at 12:21 PM, Sterpu Victor <vi...@caido.ro> wrote:
>
>> Hello
>>
>> I have a web page that asks for client certificate.
>> These are the options for this:
>>
>> SSLVerifyClient require
>> SSLVerifyDepth 10
>>
>> How does SSLVerifyClient verifies the client certificate?
>> This option protects against certificates manual made with a fake
>> public-private key pair?
>> So can someoane make a certificate identical with the original, attach
>> another set of public and private keys and pretend to be someoane else?
>>
>> Thank you
>>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
>
> *DISCLAIMER: Acest mesaj de posta electronica si documentele aferente sunt
> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt mod
> de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj, este
> interzis sa actionati in baza acestor informatii. Citirea, copierea,
> distribuirea, dezvaluirea sau utilizarea in alt mod a informatiei continute
> in acest mesaj constituie o incalcare a legii. Daca ati primit mesajul din
> greseala, va rugam sa il distrugeti, anuntand expeditorul de eroarea
> comisa. Intrucat nu poate fi garantat faptul ca posta electronica este un
> mod sigur si lipsit de erori de transmitere a informatiilor, este
> responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv documentele
> alaturate lui) este validat si autorizat spre a fi utilizat in mediul dvs.*
>
>
Re[2]: [users@httpd] SSL - How client certificates are verified?
Posted by Sterpu Victor <vi...@caido.ro>.
I'm not sure I got this right, this is what I was thinking:
- client sends his certificate, with the public key included; the
certificate contains a signature of the client certificate made with the
private key of the CA;
- apache server has the public key of the CA and can check the signature
of the CA
Is this right?
Does this check includes OCSP verification? If not can this be done from
apache?
Thank you.
------ Original Message ------
From: "Mohanavelu Subramanian" <mh...@gmail.com>
To: users@httpd.apache.org; "Sterpu Victor" <vi...@caido.ro>
Sent: 8/23/2015 10:19:13 AM
Subject: Re: [users@httpd] SSL - How client certificates are verified?
>Hi,
>
>With the option "SSLVerifyClient require" , server mandates the client
>to send its certificate for authentication. Then the server verifies
>this client certificate against the CA certificate file configured in
>apache. If the client certificate has been signed by a valid CA, then
>the authentication is successful.
>
>There are cases where sub CA certificate can be generated from root
>certificate. So, this will end up in a hierarchy of CA certificates.
>The final sub CA certificate would be used to sign client certificate.
>With option "SSLVerifyDepth 10", the server will verify the client
>certificate to the level of 10, meaning it will verify from 0 to up the
>hierarchy 10.
>Maximum depth of CA Certificates in Client Certificate verification
>
>When the client sends its fake certificate(not signed by the CA) , the
>authentication will fail at server.
>
>Regards,
>Mohan
>
>On Sun, Aug 23, 2015 at 12:21 PM, Sterpu Victor <vi...@caido.ro>
>wrote:
>>Hello
>>
>>I have a web page that asks for client certificate.
>>These are the options for this:
>>
>>SSLVerifyClient require
>>SSLVerifyDepth 10
>>
>>How does SSLVerifyClient verifies the client certificate?
>>This option protects against certificates manual made with a fake
>>public-private key pair?
>>So can someoane make a certificate identical with the original, attach
>>another set of public and private keys and pretend to be someoane
>>else?
>>
>>Thank you
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: [users@httpd] SSL - How client certificates are verified?
Posted by Mohanavelu Subramanian <mh...@gmail.com>.
Hi,
With the option "SSLVerifyClient require" , server mandates the client to
send its certificate for authentication. Then the server verifies this
client certificate against the CA certificate file configured in apache. If
the client certificate has been signed by a valid CA, then the
authentication is successful.
There are cases where sub CA certificate can be generated from root
certificate. So, this will end up in a hierarchy of CA certificates. The
final sub CA certificate would be used to sign client certificate. With
option "SSLVerifyDepth 10", the server will verify the client certificate
to the level of 10, meaning it will verify from 0 to up the hierarchy 10.
Maximum depth of CA Certificates in Client Certificate verification
When the client sends its fake certificate(not signed by the CA) , the
authentication will fail at server.
Regards,
Mohan
On Sun, Aug 23, 2015 at 12:21 PM, Sterpu Victor <vi...@caido.ro> wrote:
> Hello
>
> I have a web page that asks for client certificate.
> These are the options for this:
>
> SSLVerifyClient require
> SSLVerifyDepth 10
>
> How does SSLVerifyClient verifies the client certificate?
> This option protects against certificates manual made with a fake
> public-private key pair?
> So can someoane make a certificate identical with the original, attach
> another set of public and private keys and pretend to be someoane else?
>
> Thank you
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
>
> *DISCLAIMER: Acest mesaj de posta electronica si documentele aferente sunt
> confidentiale. Este interzisa distribuirea, dezvaluirea sau orice alt mod
> de utilizare a lor. Daca nu sunteti destinatarul acestui mesaj, este
> interzis sa actionati in baza acestor informatii. Citirea, copierea,
> distribuirea, dezvaluirea sau utilizarea in alt mod a informatiei continute
> in acest mesaj constituie o incalcare a legii. Daca ati primit mesajul din
> greseala, va rugam sa il distrugeti, anuntand expeditorul de eroarea
> comisa. Intrucat nu poate fi garantat faptul ca posta electronica este un
> mod sigur si lipsit de erori de transmitere a informatiilor, este
> responsabilitatea dvs. sa va asigurati ca mesajul (inclusiv documentele
> alaturate lui) este validat si autorizat spre a fi utilizat in mediul dvs.*
>
>