Сертификат конечного пользователя
Сертификат конечного пользователя (End User Declaration, End User Certificate, End-use Certificate, EUC) оформляется на определенные категории товаров, имеющие двойное назначение, чтобы доказать, что эта продукция не будет использоваться для военных или других целей, и что товары не будут переданы
другой стороне.
Кто и зачем выдаёт End user certificate?
Предположим, российская компания закупает из Нидерландов товар двойного назначения. Но голландская таможня, прежде чем выпускать такой товар в Россию, потребует у продавца end-use сертификат. Иными словами, им требуется информация о том, где и как российский покупатель будет использовать этот товар двойного назначения. Поэтому нидерландский продавец должен получить у российского покупателя сертификат конечного пользователя. Итак:
1. Российская компания (покупатель) делает end-use сертификат на русском или английском языке. Желательно составить документ сразу на английском, чтобы дополнительно не делать перевод.
2. Нидерландская компания (продавец) уточняет на своей таможне нужно ли заверить End-use certificate в ТПП РФ или консульстве/посольстве (attestation/legalization by Chamber of Commerce or Embassy/Consulate). Обычно принимающей стороне достаточно заверения в ТПП.
3. Заверить сертификат конечного пользователя согласно требованиям нидерландской таможни вы можете либо самостоятельно, либо через нашу компанию. Ниже подробно описано как мы заверяем сертификат конечного пользователя.
4. Вы отправляете заверенный End User Certificate продавцу, который предъявляет его на таможне. Только после этого товар двойного назначения пропускают в Россию.
Как заверить End user certificate в ТПП РФ?
В нашем случае сертификат нужно было заверить только в Торгово-промышленной палате, заверение в посольстве Голландии в Москве не потребовалось. Компания составила сертификат на английском языке, поэтому перевод мы не делали.
Для заверения документа в ТПП РФ были собраны следующие документы:
Образец заверения Торгово-промышленной палаты РФ 
Обратите внимание: у документов, состоящих из нескольких листов, все листы должны быть сшиты. Скрепление степлером не годится. Надо прошить все листы лентой, на самой последней странице наклеить «Прошито и пронумеровано Х листов», поставить печать выдавшей организации и подпись их сотрудника.
Для оформления документов можете пользоваться инструкциями на нашем блоге, а если не хотите заниматься этим сами, то мы выполним эту услугу за вас. Сделайте свой заказ в форме ниже↓
End user certificate образец
5.2.1.4. Требования к сертификату конечного пользователя
описание продукции военного назначения, которую предполагается импортировать ;
———————————
Описание ПВН должно позволять однозначно определять продукцию, в отношении которой даны обязательства. В совокупности с указанием номера и даты контракта на поставку данной ПВН допускается применение общих описаний в соответствии с обозначениями, используемыми в контракте, например, «запасные части, вспомогательное оборудование и техническая документация к самолетам типа МиГ-29, приобретаемые по контракту N XXXXXXXXXX от 1 сентября 2005 г.». В случаях, когда на момент выдачи СКП контракт не подписан, описание должно содержать наименование и количество ПВН.
номер и дату контракта (договора), в рамках поставки по которому имеют место обязательства государства-импортера ;
———————————
В случае, если соответствующий контракт подписан.
страну конечного назначения;
описание конечного использования (например, оснащение вооруженных сил или обеспечение производства);
информацию о конечном пользователе: полные наименование и адрес органа власти (организации) ; должность, фамилия и оригинал подписи должностного лица, уполномоченного выдавать СКП;
———————————
СКП должен быть оформлен на официальном бланке уполномоченного органа иностранного государства, если иное не предусмотрено национальным законодательством.
Оформление перевода.
СКП представляется только с засвидетельствованной в соответствии с законодательством Российской Федерации копией на русском языке в случаях, когда он исполнен на иностранном языке.
———————————
Пункт 12 Положения о порядке лицензирования.
б) в легализационном штампе проставлена подпись за должностное лицо, указанное в штампе.
Сертификат конечного пользователя
система — 4.48 система (system): Комбинация взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей. Примечание 1 Система может рассматриваться как продукт или предоставляемые им услуги. Примечание 2 На практике… … Словарь-справочник терминов нормативно-технической документации
TechnologiCS — Тип Программы PDM Разработчик СиСофт Девелопмент Операционная система Windows Языки интерфейса русский Последняя версия 6.2 (сборка 15917) (24 декабря 2012[1]) … Википедия
Государственная программа — (Government program) Государственная программа это инструмент государственного регулирования экономики, обеспечивающий достижение перспективных целей Понятие государственной программы, виды государственных федеральных и муниципальных программ,… … Энциклопедия инвестора
Инфраструктура — (Infrastructure) Инфраструктура это комплекс взаимосвязанных обслуживающих структур или объектов Транспортная, социальная, дорожная, рыночная, инновационная инфраструктуры, их развитие и элементы Содержание >>>>>>>> … Энциклопедия инвестора
РМ 4-239-91: Системы автоматизации. Словарь-справочник по терминам. Пособие к СНиП 3.05.07-85 — Терминология РМ 4 239 91: Системы автоматизации. Словарь справочник по терминам. Пособие к СНиП 3.05.07 85: 4.2. АВТОМАТИЗАЦИЯ 1. Внедрение автоматических средств для реализации процессов СТИСО 2382/1 Определения термина из разных документов:… … Словарь-справочник терминов нормативно-технической документации
Opera Unite — Разработчик Opera Software … Википедия
изготовитель — 3.15 изготовитель: По ГОСТ Р 51121. Источник: ГОСТ Р 52169 2003: Обо … Словарь-справочник терминов нормативно-технической документации
Продавец — (Seller) Профессия продавец, права и обязанности продавца Профессия продавец, права и обязанности продавца, правила поведения продавца Содержание Содержание Обозначение Профессия Права и обязанности Характеристика купли продажи и участие в нем… … Энциклопедия инвестора
End user certificate образец
The certificate purpose defines the intended primary use of the certificate. The certificate purpose can be one of four settings:
Certificate Authority
A Certificate Authority (CA) issues digital certificates that contain a public key and the identity of the owner. The matching private key is not made available publicly, but kept secret by the end user who generated the key pair. The certificate is also a confirmation or validation by the CA that the public key contained in the certificate belongs to the person, organization, server or other entity noted in the certificate. A CA’s obligation in such schemes is to verify an applicant’s credentials, so that users and relying parties can trust the information in the CA’s certificates. CAs use a variety of standards and tests to do so. In essence, the Certificate Authority is responsible for saying «yes, this person is who they say they are, and we, the CA, verify that».
If the user trusts the CA and can verify the CA’s signature, then he can also verify that a certain public key does indeed belong to whoever is identified in the certificate. Browsers maintain list of well known CAs root certificates. Aside from commercial CAs, some providers issue digital certificates to the public at no cost. Large institutions or government entities may have their own CAs.
CA Hierarchy
Single/One Tier Hierarchy
Two Tier Hierarchy
Three Tier Hierarchy
Specifically the difference between a Two Tier Hierarchy is that second tier is placed between the Root CA and the issuing CA. The placement of this CA can be for a couple different reasons. The first reason would be to use the second tier CA as a Policy CA. In other words the Policy CA is configured to issue certificates to the Issuing CA that is restricted in what type of certificates it issues. The Policy CA can also just be used as an administrative boundary. In other words, you only issue certain certificates from subordinates of the Policy CA, and perform a certain level of verification before issuing certificates, but the policy is only enforced from an administrative not technical perspective.
The other reason to have the second tier added is so that if you need to revoke a number of CAs due to a key compromise, you can perform it at the Second Tier level, leaving other “branches from the root” available. It should be noted that Second Tier CAs in this hierarchy can, like the Root, be kept offline.
Obtaining a Certificate From CA
You can obtain a certificate for your business from commercial CAs. The Issuing entities of commercial CAs provide certificate with a cost.
User can directly approach to a issuing CA, in this case issuing CA will generate a Key pair on user’s behalf. Hand over the private key to the user and provide the certificate containing the public key with Issuing CA’s signature after all necessary validations as per CA’s policy.
User can also generate a Key pair of its own using some tool like Keytool in Java and generate a Certificate Signing Request (CSR) using some tool again, e.g. Keytool and then send the CSR to Issuing CA for a certificate. CSR contains the public key of the user and user identity information in a format that issuing CAs would normally expect.
User must keep the private key secret. If private key is compromised or lost then issuing CA must be informed. This is similar to loosing a credit card. CAs keep the certificates in Certificate Revocation List whose private keys believed to have been compromised or lost.
You can yourself be a CA and issue your own certificates, these are called self signed certificates but for commercial purpose your self signed certificated will not be trusted. Only established and well known CAs self signed certificates are trusted. Root certificate of a CA is always self signed.
Certificate Chain or Certificate Path
When you get a certificate for your public key from a commercial CA then your certificate is associated with a chain of certificates or sometimes called chain of trust. The number of certificates in the chain depends on the CA’s hierarchical structure. The following image shows a certificate chain for a two tier CA. The owners/users certificate is signed by a Issuing CA and issuing CA’s certificate is signed by the Root CA. Root CA’s certificate is self signed.
During a User’s certificate validation by a browser or a program, browser needs to validate the signature by finding the public key of the next issuing CA or intermediate CA. The process will continue until the root certificate is reached. Root CA is self signed and must be trusted by the browser at the end. Browsers keep all well known CAs root certificates in their trust store.
AIA Locations
When a client or application is validating a certificate it needs to not only validate the certificate that is being used but also the entire chain of the certificate. In other words, the application or client needs a certificate from each CA in the chain beginning with the issuing CA and ending with the Root CA. If the application or client does not have access to the certificates in the chain locally the application or client needs a place from which to obtain the certificates. This location is called the Authority Information Access or AIA. The AIA location is the repository where the CA certificate is stored so that it can be downloaded by clients or applications validating a certificate. The AIA location is included in the AIA extension of a certificate.
CDP Locations
Anatomy of a Certificate
A digital certificate binds a user, computer, or service’s identity to a public key by providing information about the subject of the certificate, the validity of the certificate, and applications and services that can use the certificate. Certificates issued in PKIs are structured to meet these objectives based on standards established by the Public-Key Infrastructure (X.509) Working Group (PKIX) of the Internet Engineering Tasks Force (IETF).
What is inside a Digital Certificate?
Classification
Commercial CAs uses the concept of classes for different types of digital certificates. For example VeriSign has the following classification
Other vendors may choose to use different classes or no classes at all as this is not specified in the specification, though, most do opt to use classes in some form.
Certificate Format and Encoding
The X.509 Digital certificate formats are defined using ASN.1 or Abstract Syntax Notation One, is an International Standards Organization (ISO) data representation format used to achieve interoperability between platforms.
The current structure of a X.509 v3 digital certificate looks as follows. This basically defines how a certificate contents should be written. You can check the details here.
PEM (Privacy Enhanced Mail) Encoding
The most commonly used encoding schema for X.509 certificate files is the PEM (Privacy Enhanced Mail) encoding. The full specification of PEM is in RFC 1421. But the idea of PEM encoding on X.509 certificates is very simple:
Encode the content with Base64 encoding.
Enclose the Base64 encoding output between two lines: «——BEGIN CERTIFICATE——» and «——END CERTIFICATE——«
Here is a structural sample of a PEM encoded X.509 certificate:
DER (Distinguished Encoding Rules) Encoding
DER (Distinguished Encoding Rules) is another popular encoding used to store X.509 certificate files. The Distinguished Encoding Rules of ASN.1 is an International Standard drawn from the constraints placed on BER encodings by X.509. DER encodings are valid BER encodings. DER is the same thing as BER with all but one sender’s options removed. For example, in BER a boolean value of true can be encoded in 255 ways, while in DER there is only one way to encode a boolean value of true. The full specification of DER is in RFC 1421.
PKCS Formats
PKCS refers to a group of public-key cryptography standards devised and published by RSA Security. As such, RSA Security and its research division, RSA Labs, had an interest in promoting and facilitating the use of public-key techniques. To that end, they developed (from the early 1990s onwards) the PKCS standards. They retained control over them, announcing that they would make changes/improvements as they deemed necessary, and so the PKCS standards were not, in a significant sense, actual industry standards, despite the name. Some, but not all, have in recent years begun to move into standards organizations like the IETF PKIX working group.
Real Examples
Let us check a real certificate, its details and its chain. Thank god there are certificate viewer tools that read those archaic encoding formats and show the certificates nicely! You can actually check any https url in any browser to check a X.509 digital certificate. Here we are going to check internet banking site of State Bank of India in Internet Explorer (IE).
Go to https://www.onlinesbi.com/ and click on the view certificate link as shown below.
Once you click on the view certificate link, Windows certificate viewer tool will open and show the certificate owned by State Bank of India. This certificate, as you can see in «Issued by» field is issued by VeriSign Class 3 Extended Validation SSL SGC CA.
Certificate viewer also shows the details of a certificate. There are many fields and the «Show» dropdown filters them for better viewing. The below image is showing some of the basic fields which are called version 1 fields. Here on the left you are seeing the subject, SBI, and its detail Distinguished Name (DN). On the right issuer’s DN.
Select the «Extensions Only» from the show dropdown. Please note extensions are optional but they are very common now a days. On the left you are seeing CRL Distribution point and on the right AIA location.
You can click on http://EVIntl-crl.verisign.com/EVIntl2006.crl to download the CRL. The following image shows how CRL looks like. Every certificate normally points to a CRL given by its issuer.
Click on the «Certificate Path» tab to see the certificate chain. Certificate viewer allows you see other certificates in the chain by highlighting a certificate and click on the «View Certificate» button as shown on the right below. Here the chain also shows that VeriSign is a two tier CA, where VeriSign is the Root and «VeriSign Class 3 Extended Validation SSL SGC CA» is a Issuing CA.
Click on the View Certificate button to see Issuer CA’s certificate. Also you can clink on the AIA link, i.e. http://EVIntl-aia.verisign.com/EVIntl2006.cer to get the same certificate.
The issuer CA’s certificate is as follows.
Similarly you can see the root certificate as well. Please note that for root certificate the «Issued to» or «Subject» and «Issued by» or «Issuer» fields are same. So this is a self signed certificate.
You can also see the certificates using Chrome and Firefox. Chrome uses IE’s certificate viewer but FF uses its own certificate viewer.
Certificate Validation Process
Certificate Discovery or Chain Building
The chain-building process will validate the certification path by checking each certificate in the certification path from the end certificate to the root CA’s certificate. The certificates are retrieved from the Intermediate Certification Authorities store, the Trusted Root Certification Authorities store, or from a URL specified in the AIA attribute of the certificate. If it discovers a problem with one of the certificates in the path, or if it cannot find a certificate, the certification path is discarded as a nontrusted certification path.
To improve performance, Browsers/Operating Systems may store subordinate CA certificates in the Intermediate Certification Authorities store so that future requests for the certificate can be satisfied from the store, rather than accessing the certificate through a URL.
Certificate Storage
A certificate store will often contain numerous certificates, possibly issued from a number of different CAs. In Windows systems there are separate stores known as the machine store, used by the computer, and the user store or My store used by the currently logged-on user.
In Java Environment certificates are stored in JKS files and are pointed by System Properties
Purpose
The certificate chain engine builds all possible certificate chains. The entire graph of certificate chains is constructed and then ordered by the “quality” of the chain. The best-quality chain for a given end certificate is returned to the calling application as the default chain.
Each chain is built by using a combination of the certificates available in the certificate stores and certificates available from published URL locations. Each certificate in the chain is assigned a status code. The status code indicates whether the individual certificate is:
Each status code has a precedence assigned to it. For example, an expired certificate has a higher precedence than a revoked certificate. This is because an expired certificate should not be checked for revocation status.
If different status codes are assigned to the certificates in a certificate chain, the status code with the highest precedence is applied to the certificate chain and propagated into the certificate chain status.
Path validation
For each certificate in the chain, the certificate chain engine must select a certificate of the issuing CA. This process, known as path validation, is repeated until a self-signed certificate is reached (typically, this is a root CA certificate).
There are different processes that can be used to select the certificate for an issuing CA. The actual process that is used is based on whether the certificate currently being investigated has the Authority Key Identifier (AKI) extension defined. Inspection of the AKI extension will lead to one of three matching processes being implemented:
In all cases, even if a matching certificate is not found in the store, the current certificate will still be marked as “exact match”, “key match” or “name match,” because this describes the attempted match rather than the attained match.
Caching
To increase performance, the certificate chain engine uses a least recently used (LRU) caching scheme. This scheme creates a cache entry for each certificate it encounters as it builds the certificate chain. Each cache entry includes the status of the certificate, so the best certificate chain can be built from cached items on subsequent calls to the chaining API without having to determine the status of each certificate again. After a certificate has been added to the cache, it will not be removed until it expires or is revoked.
During the path validation process, valid cached certificates will always be selected. If valid cached certificates are not found, a store search will be performed. For issuer certificates and CRLs, URL retrieval can be required to download the certificates and CRLs from the distribution point indicated in the URL.
All certificates are stored in the cache when the certificates are selected from a store or from a URL. The only difference is the location where the cached certificates are stored.
Revocation
The certificate chain engine will check each certificate in the chain to determine whether the certificate has been revoked and the reason for the revocation. The revocation checking can take place either in conjunction with the chain building process or after the chain is built. If a revoked certificate is discovered in the chain, the chain is assigned a lower quality value.