Uso sconosciuto della chiave 1.2 643.3 7.8 1. Firma elettronica (ES)

Quando inserisci il tuo account personale per una richiesta CEP, viene visualizzato un messaggio « Il computer non è configurato . Per continuare a lavorare, vai alla pagina di configurazione del computer e segui i passaggi suggeriti » ... Dopo essere andato alla pagina di configurazione e aver installato tutti i componenti necessari nel tuo account personale, viene visualizzato nuovamente un messaggio che indica che il computer non è configurato.

Per eliminare l'errore, è necessario:

1. Aggiungi l'indirizzo del tuo account personale https://i.kontur-ca.ru a siti attendibili. Per questo:

• Selezionare il menu "Start" > "Pannello di controllo" > "Opzioni Internet";
• Vai alla scheda "Sicurezza", seleziona la voce "Siti attendibili" (o "Siti attendibili") e clicca sul pulsante "Siti";
• Specificare l'indirizzo https://i.kontur-ca.ru nel campo Aggiungi alla zona il seguente indirizzo di nodo https://i.kontur-ca.ru fare clic sul pulsante "Aggiungi".

Se questo indirizzo è già nell'elenco dei siti attendibili, vai alla voce successiva.

2. Verifica che l'indirizzo del tuo account personale https://i.kontur-ca.ru sia ritenuto affidabile:

• Se stai utilizzando la versione 8 di Internet Explorer, nella pagina di autorizzazione dovresti controllare se la casella di controllo "Siti attendibili" si trova in fondo alla pagina. Se non c'è taccola, ma c'è un'iscrizione « Internet ", quindi l'indirizzo https://i.kontur-ca.ru non è stato aggiunto a siti attendibili.

• Se stai utilizzando Internet Explorer versione 9 e successive, quindi, essendo nella pagina di autorizzazione, dovresti fare clic con il pulsante destro del mouse in qualsiasi punto della pagina, selezionare "Proprietà". Nella finestra che si apre, la riga "Zona" dovrebbe contenere la scritta "Siti attendibili". In caso contrario, l'indirizzo https://i.kontur-ca.ru non è stato aggiunto ai siti attendibili.

Se l'indirizzo del tuo account personale non è determinato come affidabile, dovresti contattare l'amministratore di sistema con una richiesta per aggiungere l'indirizzo https://i.kontur-ca.ru ai siti attendibili.

3. Controlla se puoi accedere al tuo account personale. Se l'errore persiste, è necessario eseguire l'utilità RegOids dal collegamento. Questa utility configurerà automaticamente i parametri OID nel registro del computer. Puoi anche importare manualmente uno dei rami del registro, a seconda del numero di bit del sistema operativo installato:

4. Verificare che il computer utilizzi i diritti di amministratore (per verificare, andare su Start - Pannello di controllo - Account utente e sicurezza familiare - Account utente). Se i diritti non sono sufficienti, è necessario concedere all'utente tutti i diritti, per questo contattare l'amministratore.

5. Dopo aver completato il punto 3, è necessario riavviare il computer e verificare l'accesso al proprio Account personale.

Se nessuna delle istruzioni è stata utile, è necessario contattare l'assistenza tecnica all'indirizzo [e-mail protetta] La lettera deve indicare:

1. Numero diagnostico.

Per fare ciò, vai al portale diagnostico all'indirizzohttps://help.kontur.ru , premi il bottone " Avvia diagnostica " ... Una volta terminato il processo di verifica, il numero diagnostico verrà visualizzato sullo schermo. Specificare nella lettera il numero di riferimento assegnato.

2. Screenshot della finestra con l'errore (quando si utilizza Internet Explorer 9 e versioni successive, è necessario allegare anche uno screenshot della finestra "Proprietà" - vedere il punto 2).

3. Esporta e allega i seguenti rami del registro:

32 bit: HKLM \ SOFTWARE \ Microsoft \ Cryptography \ OID \ EncodingType 0 \ CryptDllFindOIDInfo
64 bit: HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ Cryptography \ OID \ EncodingType 0 \ CryptDllFindOIDInfo

1. Disposizioni generali.

   La scelta della modalità di presentazione di determinati dati e ulteriori restrizioni sulla composizione dei campi del certificato si basa sui seguenti principi:

   la presentazione dei dati nel certificato dovrebbe essere estremamente semplice e univoca al fine di escludere diverse opzioni di interpretazione del documento già nella fase di sviluppo dell'applicazione;

   la specifica così redatta dovrebbe lasciare la necessaria libertà di inserire nel certificato dati aggiuntivi di tipo arbitrario, tipici di un particolare campo di applicazione dei certificati chiave EDS;

   la composizione dei campi e dei formati per la presentazione dei dati nel certificato deve essere conforme alle raccomandazioni internazionali (vedi punto 2) ove ciò non contraddica i requisiti della Legge sulla CE;

   i certificati emessi sono utilizzati nell'Internet PKI e il periodo di validità delle chiavi pubbliche e private per tali sistemi è considerato lo stesso secondo RFC 3280 (4.2.1.4) e l'attributo Private Key Usage Period non dovrebbe essere incluso nel certificato.

2. Raccomandazioni internazionali. Questo documento è stato sviluppato tenendo conto delle raccomandazioni internazionali:
   • RFC 3280 (aggiornato a RFC 2459) Infrastruttura a chiave pubblica Internet X.509. Certificato e profilo dell'elenco di revoche di certificati (CRL).
   • RFC 3039 Infrastruttura a chiave pubblica Internet X.509. Profilo certificato qualificato - Questa RFC propone requisiti generali per la sintassi (composizione) dei certificati, il cui uso è legalmente significativo.
3. Composizione e scopo dei campi del certificato.

   Questa sezione fornisce una descrizione dei principali campi di un certificato a chiave pubblica conforme alla legge "Sulla firma elettronica digitale" del 01.10.2002.

   I concetti, le designazioni e la terminologia utilizzati nella sezione si basano su RFC 3280 e RFC 3039, che, a loro volta, si basano su ITU-T X.509 versione 3. un certificato che implementa i requisiti per la composizione di un set di certificati EDS all'articolo 6 della legge sull'EDS.

   Per tutti i campi del certificato che implicano valori stringa in lingua russa, è preferibile utilizzare la codifica universale UTF-8 (tipo UTF8String).

   Lo scopo di questa sezione è determinare la composizione e lo scopo dei campi del certificato senza tenere conto dei requisiti di una particolare autorità di certificazione. I documenti che regolano il funzionamento dell'autorità di certificazione possono limitare la composizione dei campi del certificato e l'insieme degli attributi utilizzati per identificare la CA ei proprietari dei certificati chiave di firma.

   Versione
   Tutti i certificati emessi dovere avere la versione 3.

   Numero di serie
   Campo SerialNumber dovere contenere "... il numero di registrazione univoco del certificato di chiave di firma" (articolo 6, comma 1, comma 1). L'unicità del numero di certificato deve essere rispettata nell'ambito di questa autorità di certificazione (CA).

   Validità
   Campo di validità dovere contenere "... le date di inizio e di scadenza del certificato di chiave di firma situato nel registro dell'autorità di certificazione" (art. 6, comma 1, comma 1).

   OggettoPublicKeyInfo
   Campo SubjectPublicKeyInfo dovere contenere "... la chiave pubblica della firma digitale elettronica" (articolo 6, comma 1, comma 3).

   Emittente
   La legge federale "Sull'EDS" presuppone l'emissione di certificati solo a persone fisiche, questa disposizione si applica anche ai certificati delle CA stesse e ai certificati di risorse. Per ottemperare ai requisiti formali della Legge Federale, si propone di indicare le reali informazioni dell'organizzazione negli attributi dei certificati della CA e le risorse negli attributi, considerando che tale certificato è stato rilasciato a un soggetto autorizzato della CA o la Risorsa e le informazioni specificate devono essere interpretate e registrate come un certificato per uno pseudonimo, il che è consentito dalla Legge Federale "Sull'EDS".
   Campo emittente dovere identificare in modo univoco l'organizzazione che rilascia il certificato e contenere il nome ufficialmente registrato dell'organizzazione.
   I seguenti attributi possono essere utilizzati per l'identificazione:

   nome del paese	(id-at 6)
   statoONomeProvincia	(id-at 8)
   localitàNome	(id-at 7)
   nome dell'organizzazione	(id-a 10)
   nomeUnità organizzativa	(id-at 11)
   indirizzo postale	(id-at 16)
   numero di serie	(id-at 5)

   Campo emittente dovere assicurarsi di includere attributi che descrivano "il nome e l'ubicazione dell'autorità di certificazione che ha emesso il certificato della chiave di firma" (articolo 6, comma 1, paragrafo 5).

   Nome dovere essere specificato nell'attributo nomeorganizzazione. Quando si utilizza l'attributo nomeorganizzazione può essere

   Posizione del centro di certificazione può essere essere specificato utilizzando un set di attributi countryName, stateOrProvinceName, localityName (ognuno dei quali è facoltativo) o utilizzando un singolo attributo postalAddress. Con uno qualsiasi dei metodi di cui sopra, la posizione della CA deve essere presente nel certificato.

   dovere contenere l'indirizzo legale del centro di certificazione. Lo spazio (carattere "0x20") deve essere utilizzato come separatore.

   Attributo del campo Soggetto serialNumber dovere utilizzato per le collisioni di nomi.

   Materia
   Per rappresentare il DN (Distinguished Name) del titolare del certificato Maggio vengono utilizzati i seguenti attributi:

   nome del paese	(id-at 6)
   statoONomeProvincia	(id-at 8)
   localitàNome	(id-at 7)
   nome dell'organizzazione	(id-a 10)
   nomeUnità organizzativa	(id-at 11)
   titolo	(id-at 12)
   nome comune	(id-at 3)
   pseudonimo	(id-at 65)
   numero di serie	(id-at 5)
   indirizzo postale	(id-at 16)

   Per ottemperare ai requisiti formali della Legge Federale, si propone di indicare le reali informazioni dell'organizzazione negli attributi dei certificati della CA e le risorse negli attributi, considerando che tale certificato è stato rilasciato a un soggetto autorizzato della CA o la Risorsa e le informazioni specificate devono essere interpretate e registrate come un certificato per uno pseudonimo, il che è consentito dalla Legge Federale "Sull'EDS".

   Il campo soggetto dovere assicurarsi di contenere le seguenti informazioni: “cognome, nome e patronimico del titolare del certificato di chiave di firma o pseudonimo del titolare” (art. 6, comma 1, comma 2).

   Cognome, nome e patronimico del titolare dovere essere contenuto nell'attributo commonName e corrispondere a quelli specificati nel passaporto. Lo spazio (carattere "0x20") deve essere utilizzato come separatore.

   Alias ​​proprietario dovere contenuto nell'attributo pseudonimo.

   L'uso di uno di questi attributi esclude l'uso dell'altro.

   Il resto degli attributi è facoltativo.

   "Se necessario, sulla base di documenti giustificativi, la posizione (indicante il nome e l'ubicazione dell'organizzazione in cui è stabilita tale posizione) deve essere indicata nel certificato della chiave di firma sulla base dei documenti giustificativi ..." (Articolo 6 , comma 2).

   Posizione del titolare del certificato Dovrebbe essere specificato nell'attributo title. Valore attributo dovere corrispondono a quanto riportato nei documenti attestanti la posizione stabilita per il titolare del certificato.

   L'attributo del titolo, come da RFC 3039, dovere incluso nell'estensione subjectDirectoryAttributes. Tuttavia, questo documento (e RFC 3280) consente di includerlo nel campo dell'oggetto.

   Quando si utilizza l'attributo title, assicurarsi di dovere includere attributi che descrivono il nome e l'ubicazione dell'organizzazione in cui è stabilita questa posizione.

   Nome dell'azienda dovere essere specificato nell'attributo nomeorganizzazione. Valore attributo dovere coincidano con l'iscrizione del nome dell'ente nell'atto costitutivo o in altri documenti equivalenti. Quando si utilizza l'attributo nomeorganizzazione può essere viene utilizzato anche l'attributo OrganizationUnitName.

   Sede dell'organizzazione può essere essere specificato utilizzando un set di attributi countryName, stateOrProvinceName, localityName (ognuno dei quali è facoltativo) o utilizzando un singolo attributo postalAddress.

   L'attributo postalAddress, se utilizzato, dovere contenere l'indirizzo legale dell'organizzazione o l'indirizzo di registrazione del proprietario del certificato della chiave di firma (per un individuo).

   Se l'attributo organizationName è presente, gli attributi countryName, stateOrProvinceName, localityName e postalAddress dovere interpretata come la sede dell'organizzazione.

   Attributi facoltativi del campo oggetto (countryName, stateOrProvinceName, localityName, organizationName, OrganizationUnitName, title, postalAddress) Maggio essere incluso, se definito dalle regole della CA, al posto del campo soggetto nell'estensione subjectDirectoryAttributes (vedi 3.8.1). In questo caso, sono non dovrebbe essere incluso nel soggetto e non può essere utilizzato per distinguere tra i proprietari dei certificati chiave di firma.

   Attributo SerialNumber dovere incluso nel campo dell'oggetto del certificato per le collisioni di nomi. Ha anche può essere da includere se è determinato dal regolamento del centro di certificazione.

   Attributo SerialNumber può essere:

   • essere arbitrario (assegnato dall'autorità di certificazione stessa);
   • contenere un identificatore (numero) assegnato da un'organizzazione statale (o altra) (ad esempio, TIN, serie e numero di passaporto, numero di carta d'identità, ecc.).

   1. Estensioni obbligatorie
      dovere includere le seguenti estensioni:

      • KeyUsage (id-ce 15)
      • CertificatePolicies (id-ce 32)

      1. Utilizzo della chiave
         Affinché il certificato possa essere utilizzato per verificare la firma digitale, nell'estensione keyUsage dovere i bit digitalSignature (0) e nonRepuduation (1) siano impostati.

         CertificatePolicy
         L'estensione certificatePolicies ha lo scopo di definire l'ambito dell'applicazione giuridicamente rilevante di un certificato.
         "... il nome dell'EDS indica con cui viene utilizzata questa chiave pubblica ..." (Articolo 6, comma 1, comma 4), "... informazioni sul rapporto, nell'attuazione del quale un documento informatico con una firma elettronica digitale avrà valore legale…” (art. 6, comma 1, comma 6) e gli altri dati che disciplinano la procedura per l'ottenimento e l'utilizzo dei certificati di chiave di firma, può essere sono disponibili presso il CPSuri (Certificate Practice Statement URI) specificato in questa estensione.

   Estensioni opzionali
   Il certificato della chiave di firma Maggio includere eventuali altre estensioni. Quando si includono estensioni nel certificato della chiave EDS, è necessario garantire la coerenza e l'univocità delle informazioni presentate nel certificato.
   Questo documento non regola l'uso delle estensioni, ad eccezione dell'estensione subjectDirectoryAttributes (id-ce 9).

   1. OggettoDirectoryAttributes
      Estensione oggettoDirectoryAttributes può essere contenere attributi oltre alle informazioni fornite nel campo dell'oggetto.
      Oltre agli attributi elencati nella RFC 3039, si consiglia di supportare i seguenti attributi nell'estensione subjectDirectoryAttributes:

      qualificazione	{-}
      nome del paese	(id-at 6)
      statoONomeProvincia	(id-at 8)
      localitàNome	(id-at 7)
      nome dell'organizzazione	(id-a 10)
      nomeUnità organizzativa	(id-at 11)
      titolo	(id-at 12)
      indirizzo postale	(id-at 16)

      "Se necessario, il certificato della chiave di firma sulla base dei documenti giustificativi deve indicare ... le qualifiche del proprietario del certificato della chiave di firma" (articolo 6, paragrafo 2).

      Dati sulle qualifiche del titolare del certificato di chiave EDS dovere specificato nell'attributo di qualifica. Questo attributo non è definito nelle raccomandazioni internazionali (vedi clausola 2) ed è soggetto a registrazione.

      Se gli attributi countryName, stateOrProvinceName, localityName, OrganizationName, OrganizationUnitName, title, postalAddress sono inclusi nell'estensione subjectDirectoryAttributes, essi non dovrebbe incluso nel campo della materia.

      Per memorizzare altre informazioni sul proprietario del certificato della chiave di firma Maggio utilizzare altri attributi (già registrati o soggetti a registrazione) che non contraddicano le restrizioni imposte dall'estensione certificatePolicies e altri documenti che regolano il funzionamento della CA.

Applicazione ASN1

id-at: Valore OID: 2.5.4
Descrizione dell'OID: Tipi di attributi X.500.
id-ce: Valore OID: 2.5.29
Descrizione dell'OID: Identificatore oggetto per le estensioni del certificato versione 3.

2.5.4.5 id-at-serialNumber serialNumber ATTRIBUTE :: = (WITH SYNTAX PrintableString (SIZE (1..64)) EQUALITY MATCHING RULE caseIgnoreMatch SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch ID id-at-serialNumber)

(RFC 3039)
Il tipo di attributo serialNumber DEVE, quando presente, essere utilizzato per differenziare i nomi in cui il campo soggetto sarebbe altrimenti identico. Questo attributo non ha una semantica definita oltre a garantire l'unicità dei nomi dei soggetti. Può contenere un numero o un codice assegnato dalla CA o un identificatore assegnato da un'autorità governativa o civile. È responsabilità della CA garantire che serialNumber sia sufficiente per risolvere eventuali conflitti di nomi di soggetti.

2.5.4.3 - id-at-commonName

Valore OID: 2.5.4.3

Descrizione dell'OID: Il tipo di attributo del nome comune specifica un identificatore di un oggetto. Un nome comune non è un nome di directory; è un nome (possibilmente ambiguo) con il quale l'oggetto è comunemente noto in un ambito limitato (come un'organizzazione) ed è conforme alle convenzioni di denominazione del paese o della cultura a cui è associato.

CommonName ATTRIBUTE :: = (SOTTOTIPO DI nome CON SINTASSI DirectoryString (ub-nome-comune) ID (id-at-commonName))

(RFC 3039: profilo certificato qualificato)
Valore OID: 2.5.4.65

pseudonimo ATTRIBUTE :: = (SOTTOTIPO DI nome CON SINTASSI DirectoryString ID (id-at-pseudonimo))

Valore OID: 2.5.29.17

Descrizione dell'OID: id-ce-subjectAltName Questa estensione contiene uno o più nomi alternativi, utilizzando una varietà di forme di nome, per l'entità che è vincolata dalla CA alla chiave pubblica certificata.

SubjectAltName ESTENSIONE :: = (SYNTAX GeneralNames IDENTIFICATO DA id-ce-subjectAltName) GeneralNames :: = DIMENSIONE SEQUENZA (1..MAX) OF GeneralName GeneralName :: = CHOICE (otherName ISTANCE OF OTHER-NAME, rfc822Name IA5String5, dNSName *) x400Address ORAddress, directoryName Name, ediPartyName EDIPartyName, uniformResourceIdentifier IA5String, IPAddress OCTET STRING, IDregistrato IDENTIFICATORE OGGETTO) (*) - stringa arbitraria. OTHER-NAME :: = SEQUENCE (type-id OBJECT IDENTIFICATORE valore EXPLICIT ANY DEFINED BY type-id)

Valore OID: 2.5.4.16

Descrizione dell'OID: Il tipo di attributo Indirizzo postale specifica le informazioni sull'indirizzo per la consegna fisica dei messaggi postali da parte dell'autorità postale all'oggetto indicato. Un valore di attributo per l'indirizzo postale sarà generalmente composto da attributi selezionati dalla versione 1 dell'indirizzo postale non formattato MHS O / R secondo CCITT Rec F.401 e limitato a 6 righe di 30 caratteri ciascuna, incluso un nome del paese postale. Normalmente le informazioni contenute in tale indirizzo potrebbero includere il nome di un destinatario, indirizzo, città, stato o provincia, codice postale ed eventualmente un numero di casella postale a seconda delle esigenze specifiche dell'oggetto nominato.

PostalAddress ATTRIBUTE :: = (CON SINTASSI PostalAddress EQUALITY MATCHING RULE caseIgnoreListMatch SUBSTRINGS MATCHING RULE caseIgnoreListSubstringsMatch ID id-at-postalAddress) PostalAddress :: = DIMENSIONE SEQUENZA (1..ub-postalString-address (u) OF Directory

Valore OID: 2.5.4.12

Descrizione dell'OID: Il tipo di attributo Titolo specifica la posizione o la funzione designata dell'oggetto all'interno di un'organizzazione. Un valore di attributo per Titolo è stringa.

Title ATTRIBUTE :: = (SOTTOTIPO DI nome CON SINTASSI DirectoryString (ub-title) ID id-at-title) id-ce-certificatePolicies IDENTIFICATORE OGGETTO :: = (id-ce 32) certificatePolicies :: = SEQUENCE SIZE (1 .. MAX) OF PolicyInformation PolicyInformation :: = SEQUENCE (policyIdentifier CertPolicyId, policyQualifiers SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo FACOLTATIVO) CertPolicyId :: = OBJECT IDENTIFIER PolicyQualifierInfo :: = SEQUYENCE (policyQualifierIdifierId PolicyQualIED) per Internet policy- :: = (id-pkix 2) id-qt-cps IDENTIFICATORE OGGETTO :: = (id-qt 1) id-qt-unotice IDENTIFICATORE OGGETTO :: = (id-qt 2) PolicyQualifierId :: = IDENTIFICATORE OGGETTO (id- qt-cps | id-qt-unotice) Qualifier :: = CHOICE (cPSuri CPSuri, userNotice UserNotice) CPSuri :: = IA5String UserNotice :: = SEQUENCE (noticeRef NoticeReference FACOLTATIVO, esplicito FACOLTATIVO) DisplayText NoticeReference :: = SEQUENCE (organi ization DisplayText, NoticeNumbers SEQUENCE OF INTEGER) DisplayText :: = CHOICE (visibleString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE (1..200)))

In conformità con le Condizioni tecniche per l'attuazione delle azioni da parte di AEI PRIME CJSC per divulgare informazioni su titoli e altri strumenti finanziari approvati dalla Banca di Russia (), i documenti elettronici contenenti informazioni pubbliche devono essere firmati dall'oggetto della divulgazione delle informazioni con un maggiore firma elettronica qualificata (v. p. 1.7 del Disciplinare). Questo requisito entra in vigore a partire dal 1 febbraio 2017.

Attualmente è iniziato un periodo di prova per l'applicazione della firma elettronica sul server di divulgazione PRIME, che durerà fino al 31 gennaio 2017 compreso.

Per testare la funzionalità, i client PRIME possono utilizzare qualsiasi certificato chiave ES ottenuto in precedenza per questa persona giuridica.

Dal 1 febbraio 2017, su richiesta delle Condizioni Tecniche (vedi clausole 1.7. E 9.6.), il certificato qualificato della chiave di verifica della firma elettronica dell'utente deve soddisfare i requisiti per la forma del certificato qualificato stabiliti con decreto del FSB della Russia del 27 dicembre 2011 n. 795 "Sull'approvazione Requisiti per la forma di un certificato qualificato della chiave di verifica della firma elettronica". L'estensione del certificato utente "Enhanced Key" (identificatore oggetto 2.5.29.37) deve contenere un identificativo oggetto per la divulgazione delle informazioni PRIME - OID 1.2.643.6.42.5.5.5

L'accesso all'account personale dell'utente di divulgazione delle informazioni "PRIME" sarà effettuato utilizzando il LOGIN e la PASSWORD precedentemente ricevuti dal cliente.

Le azioni del cliente per pubblicare messaggi nel feed di divulgazione delle informazioni, pubblicare documenti su una pagina su Internet, apportare modifiche alla scheda di registrazione dell'emittente nel sistema di divulgazione delle informazioni devono essere confermate da una firma elettronica.

Per utilizzare l'ES sul server di divulgazione delle informazioni PRIME, il client deve prima installare il plug-in (l'installazione è gratuita per gli utenti e non richiede molto tempo). Vedi sotto per le istruzioni sull'installazione del plugin.

Nell'account personale dell'utente della divulgazione delle informazioni dopo che il cliente ha installato il plug-in durante la compilazione di moduli per la pubblicazione di un messaggio nella barra multifunzione di divulgazione o la pubblicazione di un documento su Internet, nonché quando si modificano i dati della scheda di registrazione , compariranno campi aggiuntivi "Firma elettronica del documento", dove sarà necessario selezionare quello visualizzato nel corrispondente nel campo di servizio il certificato della chiave di firma e fare clic sul pulsante "Firma". Pertanto, il cliente confermerà le sue azioni per divulgare informazioni o apportare modifiche alla sua scheda di registrazione.

• Dopo aver firmato il messaggio con una firma elettronica, il cliente deve fare clic sul pulsante "Pubblica"
• Dopo aver firmato il documento con una firma elettronica, il cliente deve fare clic sul pulsante "Aggiungi documento".
• Dopo aver firmato la firma elettronica delle modifiche nella scheda di registrazione, il cliente deve cliccare sul pulsante "Invia modulo di identificazione".

Si prega di notare che tutti i messaggi inviati dai clienti tramite il proprio account personale tramite l'autorizzazione "Test login (work with electronic signature)" verranno pubblicati nel feed Informativa in modalità di lavoro. Tutti i documenti inviati dai clienti tramite il proprio account personale tramite l'autorizzazione "Test login (work with electronic signature)" verranno automaticamente pubblicati sulle pagine degli emittenti in modalità di lavoro.

In caso contrario, la procedura per le azioni dell'emittente nell'account personale sul server di divulgazione delle informazioni PRIME non cambia.

Grazie mille, Mikhail, abbiamo fatto tutto prontamente e la cosa principale mi è chiara ... Dato che abbiamo trovato un linguaggio comune. Vorrei continuare la comunicazione con voi in futuro. Spero in una proficua collaborazione.

Olesya Mikhailovna - Direttore Generale LLC "VKS"

A nome dell'impresa unitaria statale "Sevastopol Aviation Enterprise" esprimiamo la nostra gratitudine per la professionalità e l'efficienza della vostra azienda! Auguriamo alla vostra azienda una continua prosperità!

Guskova Lilia Ivanovna - allenatore. SUA "SAP"

Grazie, Mikhail, per il tuo aiuto con il design. Impiegato molto qualificato +5!

Nadia Shamilevna - imprenditrice IP Anoshkina

A nome della società "AKB-Auto" e per conto mio, esprimo la mia gratitudine a voi e a tutti i dipendenti della vostra azienda per il lavoro produttivo e di alta qualità, l'atteggiamento sensibile alle esigenze del cliente e l'efficienza nell'esecuzione del lavoro ordinato.

Nasibullina Alfira - Senior Manager"AKB-Auto"

Vorrei ringraziare il consulente Mikhail per l'ottimo lavoro, le consulenze tempestive e complete. È molto attento ai problemi e alle domande del cliente, pronta alla soluzione delle situazioni più difficili, mi sembrerebbe. È un piacere lavorare con Mikhail!!! Ora consiglierò la tua azienda ai miei clienti e amici. E anche i consulenti del supporto tecnico sono molto educati, attenti, aiutati a far fronte alla complessa installazione della chiave. Grazie!!!

Olga Sevostyanova.

L'acquisizione di una chiave si è rivelata molto facile e persino divertente. Molte grazie per l'assistenza al manager Mikhail. Spiega cose complesse e massicce da capire, in modo succinto, ma molto chiaro. Inoltre, ho chiamato la hotline gratuita e online, insieme a Mikhail, ho lasciato una richiesta. Ho ricevuto una chiave fatta in 2 giorni lavorativi. In generale, lo consiglio se risparmi tempo, ma allo stesso tempo vuoi avere una comprensione di cosa acquisti e per cosa paghi. Grazie.

Levitsky Alexander Konstantinovich Samara

Gratitudine personale al consulente Mikhail Vladimirovich per la pronta consulenza e il lavoro sulla ricezione accelerata del certificato ES. Durante la consultazione preliminare, viene selezionato l'insieme ottimale di singoli servizi. Il risultato finale è immediato.

Stoyanova N.L. - Capo contabile LLC "SITEKRIM"

Grazie per il vostro lavoro tempestivo e l'aiuto competente! Sono rimasta molto soddisfatta della consulenza!

Dmitry Fomin

Expert Sistema LLC ringrazia il consulente Mikhail per il tempestivo lavoro! Auguriamo alla tua azienda crescita e prosperità!

Sukhanova M.S. - PeritoLLC "Sistema esperto", Volgograd

Grazie al consulente che si è presentato come Mikhail per il suo tempestivo lavoro con i clienti.

Stepan Gennadievich Ponomarev

Molte grazie al consulente Mikhail per la sua assistenza nell'ottenere un EDS. Per un lavoro tempestivo e consigli su problemi che sorgono nel processo di registrazione.

Leonid Nekrasov

L'azienda, rappresentata dal suo consulente Mikhail, fa l'impossibile! Accelerazione dell'accreditamento in meno di 1 ora! Pagamento alla consegna del servizio. Pensavo non potesse succedere. Con piena responsabilità, posso consigliarti di contattare il Centro per il rilascio delle firme elettroniche.

Vadim Malykh
02.10.2013

Tempo fa, nel gruppo "Forum Rus" su Facebook, c'era una discussione sull'uso delle autorità nei sistemi informativi (la discussione non era sull'argomento, lo puoi vedere nei commenti qui sotto). L'essenza della controversia è che a causa degli OID (identificatore dell'oggetto) dei sistemi informativi, che devono essere registrati nei certificati di firma elettronica qualificata (ES) dei funzionari, questi stessi ES devono essere cambiati anche più di una volta all'anno (che è dettato dai requisiti di sicurezza) e questo, a sua volta, porta a complicazioni e costi aggiuntivi, dal momento che la maggior parte delle autorità lavora con CA commerciali senza averne una propria. Il problema è esacerbato dalla mancanza di una comprensione comune di ciò che esattamente questi OID danno e quanto siano necessari e/o obbligatori.

Durante la disputa, il mio avversario mi ha avvertito che a causa dell'ignoranza di alcuni fondamenti della materia, potrei avere alcuni problemi con la legge in futuro. Non potevo ignorare un simile avvertimento da parte di un collega, quindi ho deciso di ricercare di nuovo attentamente questo argomento e assicurarmi di aver capito tutto e di farlo correttamente. Di seguito sono riportati alcuni dei risultati di questa escursione nell'area tematica. Forse qualcuno sarà interessato.

Partendo dai concetti di base, la firma elettronica si basa su algoritmi di crittografia asimmetrica. La caratteristica principale di questi algoritmi è che vengono utilizzate due chiavi diverse per crittografare e decrittografare un messaggio. Il grande pubblico ha più familiarità con gli algoritmi simmetrici, quando con una chiave (o password) si cifra e si decrittografa un messaggio, ad esempio si archivia un file con una password o si protegge un documento MS Word.

Molte cose si basano su algoritmi di crittografia asimmetrica, sebbene il solo fatto che vengano utilizzate chiavi diverse per la crittografia e la decrittografia non consentirebbe ancora di trovare alcuna applicazione utile per questi algoritmi. Per fare ciò, devono avere alcune proprietà aggiuntive. Innanzitutto, le chiavi non dovrebbero essere calcolabili, ovvero, conoscendo una chiave, non è possibile calcolare la seconda. È anche molto importante che chiavi di decrittazione diverse corrispondano a chiavi di crittografia diverse e viceversa: solo una chiave di crittografia corrisponde a una chiave di decrittazione.

Cosa c'entra la firma con questo? Dopotutto, dobbiamo firmare il documento, non crittografarlo. Per prima cosa devi capire cos'è una firma e a cosa serve. Quando apponi la tua firma autografa su un documento cartaceo, certifichi in tal modo che sei stato tu (e non qualcun altro) a vedere (e accettare) questo particolare documento (e non qualcun altro). La proprietà più importante di una firma è il non ripudio. Ciò significa che firmando il documento, non puoi in seguito rifiutare questo fatto. Nel caso di una firma cartacea, verrai colto da un esame grafologico, nel caso di uno elettronico, con metodi matematici basati su algoritmi di crittografia asimmetrica.

Come funziona tutto in poche parole. Prendiamo un algoritmo di crittografia asimmetrico, generiamo una coppia di chiavi (per crittografia e decrittografia). Diamo la chiave di crittografia alla persona che firmerà i documenti. Deve tenerlo sempre con sé e non darlo a nessuno. Pertanto, si chiama chiave "privata". Diamo l'altra chiave (decrittazione) a tutti, quindi è "aperta". Quando si firma un documento, una persona deve crittografarlo con la propria chiave privata. In effetti, non è il documento stesso ad essere crittografato, poiché può essere piuttosto grande e in realtà non è necessario crittografarlo. Pertanto, si ottiene un hash per il documento: è una certa sequenza numerica con un alto grado di probabilità che è diversa per documenti diversi, come una "impronta digitale" del documento. È crittografato con la chiave privata del firmatario. Questo hash crittografato è la firma elettronica del documento. Avendo ora un documento, una firma e una chiave pubblica, chiunque può facilmente verificare che questo particolare documento sia stato firmato con questa particolare chiave privata. Per fare ciò, otteniamo di nuovo l'hash del documento, decrittografiamo la firma con la chiave pubblica e confrontiamo. Si dovrebbero ottenere due sequenze numeriche identiche.

Tutto questo va bene, ma finora abbiamo ottenuto il non ripudio della firma per la chiave privata, cioè abbiamo dimostrato che il documento è firmato con una chiave specifica. Dobbiamo provare che è stato firmato da una persona specifica. Per questo esistono autorità di certificazione e certificati digitali. La cosa più importante che fa l'autorità di certificazione è certificare che la chiave privata appartiene a una persona specifica. A garantire ciò è l'autorità di certificazione che genera le coppie di chiavi e le rilascia personalmente nelle mani dei titolari (ci sono opzioni per procura, da remoto, ma questi sono dettagli). Insieme alle chiavi, viene generato un certificato digitale: si tratta di un documento elettronico (a volte la sua presentazione cartacea), che contiene informazioni sul proprietario della chiave, sulla chiave stessa, sul centro di certificazione e alcune altre informazioni. Il proprietario, di norma, riceve tutto questo materiale su un supporto sicuro (smart card, ru-token, ecc.), che contiene una chiave privata e un certificato con una chiave pubblica incorporata. Il supporto stesso deve essere sempre con te e il certificato con la chiave pubblica copiata da esso può essere dato a tutti in modo che possano verificare la tua firma elettronica.

Quindi, la firma viene eseguita con una chiave privata e la verifica della firma viene eseguita con una chiave aperta. Pertanto, la frase "il documento è firmato con una serie di OID" (risuona nella suddetta controversia) è priva di significato. Solo due chiavi sono coinvolte nella procedura di firma e verifica, in 63-FZ sono denominate di conseguenza: la chiave di firma e la chiave di verifica della firma.

E quali sono questi famigerati OID? Il formato del certificato digitale X.509 consente di memorizzare le estensioni al suo interno. Questi sono alcuni attributi facoltativi con cui è possibile memorizzare informazioni aggiuntive. Ciascuno di questi attributi è un oggetto specificato da un identificatore dalla directory gerarchica. Quindi OID - Identificatore di oggetto. Non ha senso approfondire la natura degli OID stessi. In realtà, si tratta di alcune informazioni aggiuntive che potrebbero essere presenti nel certificato.

Questi attributi aggiuntivi possono essere utilizzati per scopi diversi. Possono fornire informazioni aggiuntive sul proprietario, chiavi, CA o portare alcune informazioni aggiuntive per applicazioni e servizi che utilizzano questo certificato. L'uso più comune è il controllo degli accessi basato sui ruoli. Ad esempio, nel certificato, puoi scrivere che il proprietario della chiave è il capo dell'organizzazione, e questo gli darà la possibilità di accedere immediatamente alle funzioni e alle informazioni necessarie in tutti gli IS, senza dover contattare gli amministratori di ciascuno IS e modificare le impostazioni di accesso. Tutto questo, ovviamente, a condizione che tutti questi IS utilizzino il certificato dell'utente per l'autorizzazione e analizzino lo stesso attributo allo stesso modo (per questo gli attributi vengono selezionati dalla directory e non impostati arbitrariamente).

A causa delle diverse applicazioni, riceviamo due certificati di natura completamente diversa. Uno - certifica che sono io, e questo è sempre il caso. Per una buona ragione, potrebbe essere rilasciato una o più volte nella vita, come un passaporto. Tuttavia, a causa dell'imperfezione degli algoritmi crittografici esistenti, per motivi di sicurezza, questi certificati ora devono essere rinnovati ogni anno. Il secondo tipo di certificato gestisce informazioni aggiuntive e può cambiare molto più spesso di una volta all'anno. Può essere paragonato a un biglietto da visita. La posizione, la posta elettronica, il telefono sono cambiati, bisogna fare nuovi biglietti da visita.

Nel mondo, questi due tipi di certificati sono chiamati, rispettivamente, Public Key Certificate (PKC) e Attribute Certificate (o Authorization Certificate - AC). Un certificato del secondo tipo può essere rilasciato molto più spesso del primo, da un'altra organizzazione e dovrebbe essere più accessibile e più facile da ottenere rispetto a un certificato personale a "chiave pubblica". In ogni caso, questo è quanto consiglia la RFC 3281, che si occupa di questo tipo di certificato. Il certificato di secondo tipo deve solo contenere un riferimento al certificato a chiave pubblica in modo che il sistema che lo utilizza per autenticare l'utente possa prima identificare la persona che utilizza PKC.

Ora andiamo avanti velocemente verso le nostre realtà. A livello legislativo, le questioni relative all'uso delle firme elettroniche nella Federazione Russa sono regolate da due documenti principali: la legge della Federazione Russa del 06.04.2011 n. 63-FZ "Sulla firma elettronica" e l'ordine dell'FSB della Federazione Russa del 27.12.2011 n. 795 "Approvando i requisiti per il modulo un certificato qualificato della chiave di verifica della firma elettronica ". La composizione di un certificato qualificato è descritta nell'ordine 795° (parte II "Requisiti per l'insieme dei campi di un certificato qualificato") e non esistono requisiti per gli attributi che controllano l'autorizzazione in nessun sistema informativo. Come attributi obbligatori aggiuntivi, vengono indicate solo le informazioni che consentono di identificare una persona fisica o giuridica nella Federazione Russa (TIN, SNILS, ecc.). Sebbene né la legge né l'ordine dell'FSB vietino l'inclusione di altre informazioni in un certificato qualificato.

Come si vede, nessuna norma legislativa impone la presenza obbligatoria in un certificato qualificato di attributi relativi all'autorizzazione in qualsiasi sistema informativo. Da dove vengono, allora, questi requisiti? E provengono dagli sviluppatori (o "proprietari") di sistemi specifici. Prendiamo, ad esempio, le "Linee guida per l'uso delle firme elettroniche nell'interazione elettronica tra agenzie (versione 4.3)" pubblicate sul portale tecnologico SMEV. Infatti, nel paragrafo 6 di questo documento si legge: “Quando si preparano le informazioni per la formazione di un certificato EP-JV, è necessario determinare la necessità di richiedere informazioni a Rosreestr (estratti dall'USRR). Se tale richiesta è necessaria, nel campo “Improved Key” (OID = 2.5.29.37) del certificato EP-SP, deve essere indicato l'OID secondo i requisiti di Rosreestr. ”. Cioè, il sistema informativo di Rosreestr utilizza questo attributo per determinare le informazioni che possono essere rilasciate al proprietario del certificato. Tuttavia, lo stesso documento contiene una nota importante, vale a dire che tale requisito è valido fino al pieno avvio dell'ESIA (servizio di autorizzazione unificato nei sistemi statali) e alla connessione del sistema Rosreestr ad esso. Questa è una nota importante, ricordiamocela.

Non mi occuperò di altri IS utilizzati nello stato. organi. Ho il sospetto che la situazione sia simile lì. Un portale di appalti pubblici, piattaforme di commercio elettronico, varie applicazioni contabili e finanziarie possono anche richiedere la presenza di alcuni OID aggiuntivi nel certificato utente. Allo stesso tempo, l'affermazione che prescrivendo l'OID del sistema informativo nel certificato, io deleghi in qualche modo la responsabilità all'autorità di certificazione, per usare un eufemismo, è errata. La CA inserisce questi dati nel certificato in base alla mia domanda. Se la mia posizione è cambiata, e ho dimenticato di richiedere la revoca del vecchio e il rilascio di un nuovo certificato, la CA non può essere responsabile della mia dimenticanza. Inoltre, la Legge 63-FZ stabilisce direttamente la responsabilità per l'uso improprio di un certificato per il suo proprietario. Al comma 6 dell'articolo 17 leggiamo:
Il titolare di un certificato qualificato è tenuto a:
1) di non utilizzare la chiave di firma elettronica e di chiedere immediatamente al centro di certificazione accreditato che ha rilasciato il certificato qualificato di risolvere tale certificato se vi è motivo di ritenere che sia stata violata la riservatezza della chiave di firma elettronica;
2) utilizzare una firma elettronica qualificata nel rispetto delle restrizioni contenute nel certificato qualificato (se tali restrizioni sono previste).

La necessità di archiviare in un certificato le informazioni sui ruoli dell'utente e l'accesso a sistemi informativi specifici porta a un problema che ha suscitato polemiche su Facebook, ovvero il certificato deve essere riemesso molto più spesso rispetto ai requisiti di sicurezza per una firma elettronica personale dettare. La posizione è cambiata: stiamo riemettendo il certificato. È apparso un nuovo IS: stiamo riemettendo il certificato. Era necessario richiedere informazioni all'IS della nuova organizzazione (Rosreestr) - stiamo riemettendo il certificato.

C'è un successo al cento per cento nel concetto chiamato nel mondo Attribute Certificate (o Authorization Certificate), che è stato menzionato sopra e in cui si consiglia di emettere questi certificati da un'altra autorità di certificazione (Attribute Authority, al contrario di Certificate Authority - una CA ordinaria che rilascia certificati di firma elettronica qualificata) e secondo uno schema semplificato. Questo certificato stesso non deve contenere la chiave di firma elettronica e le informazioni sul proprietario. Contiene invece un collegamento al certificato di chiave pubblica del proprietario, da cui è possibile ottenere il resto delle informazioni necessarie sulla persona.

Va notato che questo schema ha un'applicazione molto limitata e non risolve tutti i problemi. E se il prossimo sistema informativo decidesse di utilizzare per le proprie esigenze lo stesso campo del certificato “Improved Key” (OID = 2.5.29.37), che è già occupato dal valore Rosreestr? Non funzionerà per inserire due valori diversi in un campo. Pertanto, dovremo rilasciare un altro AC! Un altro problema è legato alla breve durata della PKC (un anno). Se disponiamo di più AC (che contengono un collegamento a un certificato personale), dovranno essere tutti riemessi dopo la scadenza del PKC. Per l'uso efficace di AC, è necessario un determinato centro di autorizzazione utente unificato in tutti i sistemi informativi e tutte le applicazioni devono utilizzare gli attributi dei certificati in modo coerente e uniforme.

Un tale unico centro di autorizzazione per lo stato. gli organi ci sono già - questo è l'ESIA. Ricordiamo la nota relativa agli OID" di Rosreestr. In futuro verranno sostituiti da informazioni provenienti dal Sistema Informativo Unificato. Altri sistemi informativi in ​​cui lavorano i dipendenti pubblici. Invece di utilizzare AC per l'autorizzazione, è necessario integrarsi con l'Unified Information System e da lì ottenere le informazioni necessarie.L'ESIA dovrebbe essere in grado di associare un certificato ES qualificato a un account, quindi i sistemi informativi saranno in grado di autenticare un utente utilizzando una chiave personale e autorizzare un utente (fornendo l'accesso a un'applicazione) attraverso un ESIA. Tale sistema sembra essere più universale e più affidabile rispetto all'uso dei campi del certificato e, in futuro, consentirà di automatizzare la gestione degli accessi. O continua a utilizzare la sua chiave ES per firmare i documenti, non è necessario riemettere nulla.