logo
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

6 Страницы«<456
Опции
К последнему сообщению К первому непрочитанному
Offline two_oceans  
#101 Оставлено : 29 ноября 2018 г. 2:34:33(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 284
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 17 раз
Поблагодарили: 66 раз в 64 постах
Цитата:
2.3.3 Широковещательные рассылки
В случае широковещательных рассылок активной стороной взаимодействия является поставщик, то есть он отправляет запросы. При этом потребители не могут посылать ответы (это контролируется СМЭВ). Подписка на рассылки производится по видам сведений.
Цитата из методических рекомендаций по работе с ЕСМЭВ 3.4.0.3. Написано не очень внятно. Я все же понимаю так, что потребитель в случае рассылки получит запрос в GetRequestRequest, но типом будет указано BROADCAST. Ну, поживем - увидим.

Отредактировано пользователем 29 ноября 2018 г. 2:36:25(UTC)  | Причина: Не указана

Offline Александра П  
#102 Оставлено : 29 ноября 2018 г. 4:29:09(UTC)
Александра П

Статус: Участник

Группы: Участники
Зарегистрирован: 28.06.2018(UTC)
Сообщений: 11

Сказал(а) «Спасибо»: 1 раз
Автор: two_oceans Перейти к цитате
Цитата:
2.3.3 Широковещательные рассылки
В случае широковещательных рассылок активной стороной взаимодействия является поставщик, то есть он отправляет запросы. При этом потребители не могут посылать ответы (это контролируется СМЭВ). Подписка на рассылки производится по видам сведений.
Цитата из методических рекомендаций по работе с ЕСМЭВ 3.4.0.3. Написано не очень внятно. Я все же понимаю так, что потребитель в случае рассылки получит запрос в GetRequestRequest, но типом будет указано BROADCAST. Ну, поживем - увидим.


В методических рекомендациях 3.4.0.3. на стр.81 есть рисунок "Последовательность обращений к веб-сервису СМЭВ при передаче сообщений с запросами и ответами", по нему очередь GetRequestRequest опрашивает поставщик, если он в неё же будет класть ответы по подписке, то сам по итогу и вычитает их. И с другой стороны, если потребитель будет получать с GetRequestRequest сообщения, то возможно заберет сообщение предназначавшееся поставщику, а не рассылочное.
В общем, в рекомендациях ничего вразумительного по подписке не сказано, пока одни догадки приходится строить..
Offline two_oceans  
#103 Оставлено : 30 ноября 2018 г. 1:32:55(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 284
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 17 раз
Поблагодарили: 66 раз в 64 постах
Ну так там схема для обычного запроса, а для рассылки просто абзац, что "задом наперед и все наоборот".
Цитата:
И с другой стороны, если потребитель будет получать с GetRequestRequest сообщения, то возможно заберет сообщение предназначавшееся поставщику, а не рассылочное.
Так точно не будет, так как у поставщика и потребителя разные очереди. Точнее в том же документе сказано, что все очереди входящие, исходящей очереди потребителя просто нет, поэтому для обычного вида сведений GetRequestRequest потребителю просто вернет ошибку, что очереди не существует. Ну и не забывайте, что по рассылке нельзя отправить ответ, то есть в конкретном виде сведений - рассылке сообщения идут только в одну сторону. Максимум можно вызвать Ack что сообщение получено.

И для каждого вида сведений также своя отдельная очередь. При чтении можно указать фильтр из какой очереди читать. Получается, что поставщик складывает в одну очередь, а читает из другой, вычитать свой ответ тоже не получится. За исключением тестирования, когда поставщик сам себе отправляет данные, поэтому читает оттуда же куда записал. Но это уже более сложный вопрос о реализации табличной маршрутизации.

Отредактировано пользователем 30 ноября 2018 г. 1:40:10(UTC)  | Причина: Не указана

Offline Bpar  
#104 Оставлено : 5 декабря 2018 г. 6:48:47(UTC)
Bpar

Статус: Участник

Группы: Участники
Зарегистрирован: 05.08.2014(UTC)
Сообщений: 11

Поблагодарили: 2 раз в 2 постах
Автор: Bpar Перейти к цитате

Братцы, может надо как-то регистрировать подписи?

Таки да, техподдержка ответила, что моя подпись не зарегистрирована в СМЭВ-3.
Такой подписи у меня пока нет, но поскольку страница проверки подписей сообщает, что всё хорошо,
UserPostedImage

думаю, что код рабочий. SMEV3sign.zip (6kb) загружен 13 раз(а).

Технология такая: Поскольку сериализация туда-назад возможно нарушает целостность подписи (экспериментально установлено, что с CallerInformationSystemSignature это действительно так, а с PersonalSignature - нет), то пакет подписывается непосредественно перед отправкой внутри службы SMEVMessageExchangePortTypeClient. Для этого в службе заменяется конструктор, в котором создаётся экземпляр класса от IEndpointBehavior, в свою очередь в котором экземпляр класса от IClientMessageInspector. И в нём в методе-событии BeforeSendRequest всё и происходит.
Также "доработан" SMEVTextMessageEncoder, который теперь обрезает оригинальную подпись в Header. Но это не принципиально.

Надеюсь, кому-то поможет.

П.С. спасибо мистеру two_oceans за помощь с проверками подписей.

Отредактировано пользователем 5 декабря 2018 г. 6:57:21(UTC)  | Причина: Не указана

Offline Lunatic  
#105 Оставлено : 7 декабря 2018 г. 7:47:22(UTC)
Lunatic

Статус: Новичок

Группы: Участники
Зарегистрирован: 19.10.2017(UTC)
Сообщений: 1
Российская Федерация

После пары дней танцев с бубном вокруг подписи, удалось получить от тестового СМЭВ3 ответ 'Отправитель сообщения не зарегистрирован.'

Работаю через WCF-сервис и основная проблема была не в алгоритме подписи (он тут уже несколько раз выложен), а в том, что при сериализации отдельных кусков пакета (например, SendRequestRequest или SenderProvidedRequestData) им не проставлялся Namespace.
А т.к. я сначала подписывал SenderProvidedRequestData а потом создавал через конструктор новый SendRequestRequest, получалось что подписываю я один XML, а в СМЭВ3 в итоге улетает другой.
Решается это добавлением атрибута [XmlRoot] с указанием нужного неймспейса для SenderProvidedRequestData (можно задать аналогичный атрибут для SendRequestRequest и сначала создавать новый реквест без подписи, сериализовать его, подписывать и добавлять в него подпись, но это не удобно).
Сервис создает partial-классы, поэтому сделать это можно в отдельном файле и при обновлении сервиса ничего не слетит:

Код:

[XmlRoot(Namespace = "urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2")]
public partial class SenderProvidedRequestData
{
}

Надеюсь кому-нибудь это поможет.


Автор: Max Zimin Перейти к цитате
Я столкнулся со следующей проблемой - я получаю ошибку при сериализации XML SendRequestRequest.
Прошу помочь с данным вопросом или дать наводку.


Если я правильно понял, это связано с ошибкой генерации WSDL, к сожалению починить это не меняя сгенерированный код у меня не получилось.
Я пока заменил массивы на списки:

Код:

private AttachmentHeaderList attachmentHeaderListField;
private RefAttachmentHeaderList refAttachmentHeaderListField;

private AttachmentContentList attachmentContentListField;

и дальше по коду

Если кто-то придумал, как это сделать не трогая автоматически-генерируемый код, буду рад подсказке.


Offline NikolayOkhlopkov11  
#106 Оставлено : 26 декабря 2018 г. 2:46:28(UTC)
NikolayOkhlopkov11

Статус: Новичок

Группы: Участники
Зарегистрирован: 26.12.2018(UTC)
Сообщений: 4
Российская Федерация

Сказал(а) «Спасибо»: 3 раз
Коллеги! С наступающим Новым годом!

Как я понял, чтобы подписывать сообщения в тестовой СМЭВ3 нужно:
либо зарегистрировать в https://sc.minsvyaz.ru/ рабочий, выданный аккредитованным УЦ сертификат.
либо "При необходимости, может быть выдан или использоваться сертификат тестового УЦ Оператора эксплуатации ИЭП."

Подскажите пожалуйста, кто нибудь получал такой тестовый сертификат? Как это сделать?

Самоподписанный или выданный тестовым УЦ Криптопро не подходят?
Offline archimed7592  
#107 Оставлено : 26 декабря 2018 г. 12:15:41(UTC)
archimed7592

Статус: Участник

Группы: Участники
Зарегистрирован: 26.02.2014(UTC)
Сообщений: 14
Российская Федерация
Откуда: Москва

Поблагодарили: 2 раз в 2 постах
Автор: NikolayOkhlopkov11 Перейти к цитате
Подскажите пожалуйста, кто нибудь получал такой тестовый сертификат? Как это сделать?


Напишите в СЦ заявку с просьбой выпустить тестовый сертификат для взаимодействия со СМЭВ3.
В ответ Вам дадут форму заявки (на техпортале её нет).
Заполните эту заявку, в ответ получите сертификат + контейнер с закрытым ключом в формате Крипто-Про.
thanks 1 пользователь поблагодарил archimed7592 за этот пост.
NikolayOkhlopkov11 оставлено 27.12.2018(UTC)
Offline two_oceans  
#108 Оставлено : 26 декабря 2018 г. 14:22:08(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 284
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 17 раз
Поблагодарили: 66 раз в 64 постах
Да, можно заявкой в СЦ. Самоподписанный не подходит, от тестового УЦ Криптопро думаю тоже не подойдет. Если уже есть сертификат ЭП-ОВ использующийся в рабочей смэв 2, он как правило подходит и для всех сред смэв 3 и можно не заморачиваться получением новых сертификатов в каждую среду. Сертификаты аккредитованных УЦ аналогично подходят всем средам смэв 3. Сертификат тестового УЦ Оператора эксплуатации ИЭП, как я понимаю, не подходит для рабочей среды и все равно потребуется получать сертификат в аккредитованном УЦ после тестирования. Короче получать тестовый сертификат имеет смысл либо если разработчик - иная организация (отдавать сертификат аккредитованного УЦ на сторону - плохая идея) или если разработка ИС/ВС займет более полугода (чтобы не терять оплаченное время действия сертификата аккредитованного УЦ).

Вообще при регистрации участника в смэв 3 у нас запросили по новой (ранее заполняли в 2013 году) заполнить форму присоединения к регламенту предоставления госуслуг в электронном виде (она на техпортале есть) и один из пунктов действующей формы как раз спрашивает: требуются ли услуги удостоверяющего центра. Предполагаю, если отметить пункт с услугами УЦ, то при регистрации участника без информационной системы пришлют форму заявки на сертификат без дополнительного запроса, но так потребуется еще 2 заявки в СЦ (на сертификат и на регистрацию первой ИС).

Наша организация заранее получила сертификат ЭП-ОВ в аккредитованном УЦ и поэтому смогли одной заявкой зарегистрировать и участника и первую информационную систему. Итого: есть разные пути, мы выбрали путь, при котором надо сделать минимум заявок в СЦ, так как у нас большая разница по времени с Москвой и каждая заявка может провисеть почти сутки на "уточнении данных".
thanks 1 пользователь поблагодарил two_oceans за этот пост.
NikolayOkhlopkov11 оставлено 27.12.2018(UTC)
Offline NikolayOkhlopkov11  
#109 Оставлено : 27 декабря 2018 г. 0:43:02(UTC)
NikolayOkhlopkov11

Статус: Новичок

Группы: Участники
Зарегистрирован: 26.12.2018(UTC)
Сообщений: 4
Российская Федерация

Сказал(а) «Спасибо»: 3 раз
Благодарю!Dancing , вроде что-то начало проясняться
Offline Соня Базурова  
#110 Оставлено : 13 марта 2019 г. 15:45:35(UTC)
Соня Базурова

Статус: Новичок

Группы: Участники
Зарегистрирован: 29.12.2014(UTC)
Сообщений: 2
Российская Федерация
Откуда: Москва

Никак не получается сформировать корректный xml-пакет (отправка начисления). При проверке на портале https://smev3.gosuslugi....portal/checkxmlform.jsp, результат:
ЭЦП не подтверждена: #I_54a59db2-3845-4915-8770-dd95394aadb1 Ошибка проверки ЭП: Нарушена целостность ЭП

MS .Net версии 3.5.

Подписываю так:
Код:

    static void SignXmlFile3(string FileName, string SignedFileName, X509Certificate2 Certificate)
    {
      string[] references = new string[2];
      references[0] = "I_54a59db2-3845-4915-8770-dd95394aadb1";
      references[1] = "SIGNED_BY_CALLER";
      
      XmlDocument doc = new XmlDocument();

      doc.Load(new XmlTextReader(FileName));

      doc.PreserveWhitespace = true;

      var signedXml = new SignedXml(doc) { SigningKey = Certificate.PrivateKey };      
      //signedXml.SafeCanonicalizationMethods.Add("urn://smev-gov-ru/xmldsig/transform");

      foreach (var referenceUri in references)
      {
        var reference = new Reference();
        reference.Uri = "#" + referenceUri;
#pragma warning disable 612
        reference.DigestMethod = CryptoPro.Sharpei.Xml.CPSignedXml.XmlDsigGost3411UrlObsolete;
#pragma warning restore 612

        var c14 = new XmlDsigExcC14NTransform();
        reference.AddTransform(c14);

        var env = new XmlDsigEnvelopedSignatureTransform();
        reference.AddTransform(env);

        var smev = new CryptoPro.Sharpei.Xml.XmlDsigSmevTransform();
        reference.AddTransform(smev);

        signedXml.AddReference(reference);
      }
      var keyInfo = new KeyInfo();
      keyInfo.AddClause(new KeyInfoX509Data(Certificate));
      signedXml.KeyInfo = keyInfo;

      signedXml.SignedInfo.CanonicalizationMethod = SignedXml.XmlDsigExcC14NTransformUrl;

#pragma warning disable 612
      signedXml.SignedInfo.SignatureMethod = CryptoPro.Sharpei.Xml.CPSignedXml.XmlDsigGost3410UrlObsolete;
#pragma warning restore 612

      signedXml.ComputeSignature();

      var xmlDigitalSignature = signedXml.GetXml();
      
      string sNUrl = "urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1";
      doc.GetElementsByTagName("SendRequestRequest", sNUrl)[0].AppendChild(
        doc.CreateNode(XmlNodeType.Element, "tns", "CallerInformationSystemSignature", sNUrl));
      doc.GetElementsByTagName("CallerInformationSystemSignature", sNUrl)[0].AppendChild(doc.ImportNode(xmlDigitalSignature, true));
     
      //return xmlDigitalSignature;

      // Сохраняем подписанный документ в файл.
      using (XmlTextWriter xmltw = new XmlTextWriter(SignedFileName, new UTF8Encoding(false)))
      {
        doc.WriteTo(xmltw);
      }    
    }


Оригинал сообщения:
Код:

<?xml version="1.0" encoding="UTF-8"?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:basic="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1" xmlns:tns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1">
    <S:Body>
        <tns:SendRequestRequest>
            <tns:SenderProvidedRequestData Id="SIGNED_BY_CALLER">
                <tns:MessageID>3784f060-d777-11e8-b0d0-941882013a1a</tns:MessageID>
                <basic:MessagePrimaryContent>
                    <req:ImportChargesRequest xmlns:org="http://roskazna.ru/gisgmp/xsd/Organization/2.1.0" xmlns:com="http://roskazna.ru/gisgmp/xsd/Common/2.1.0" xmlns:chg="http://roskazna.ru/gisgmp/xsd/Charge/2.1.0" xmlns:pkg="http://roskazna.ru/gisgmp/xsd/Package/2.1.0" xmlns:req="urn://roskazna.ru/gisgmp/xsd/services/import-charges/2.1.0" xmlns:rfd="http://roskazna.ru/gisgmp/xsd/Refund/2.1.0" xmlns:pmnt="http://roskazna.ru/gisgmp/xsd/Payment/2.1.0" Id="G_fce0c544-b08d-44bc-83d8-738f10e9d069" timestamp="2019-03-12T15:27:53.045+03:00" senderIdentifier="002648" senderRole="1">
	<pkg:ChargesPackage>
		<pkg:ImportedCharge Id="I_54a59db2-3845-4915-8770-dd95394aadb1" originatorId="002648" supplierBillID="0000980011923591101042012" billDate="2019-03-12T14:06:30.313+03:00" totalAmount="500000" purpose="Oplata" kbk="32111301031016000130" oktmo="45348000">
			<org:Payee name="FGBU" inn="6639001506" kpp="668301001" ogrn="1026601982220">
				<com:OrgAccount accountNumber="40101810045250010041">
					<com:Bank name="GU Bank" bik="044525000"/>
				</com:OrgAccount>
			</org:Payee>
			<chg:Payer payerIdentifier="1220000000007712579832" payerName="Test payer"/>
			<chg:BudgetIndex status="01" paytReason="0" taxPeriod="0" taxDocNumber="0" taxDocDate="0"/>
		</pkg:ImportedCharge>
	</pkg:ChargesPackage>
</req:ImportChargesRequest>
                </basic:MessagePrimaryContent>
                <tns:TestMessage/>
            </tns:SenderProvidedRequestData>
        </tns:SendRequestRequest>
    </S:Body>
</S:Envelope>


Подписанное сообщение:
Код:
<?xml version="1.0" encoding="UTF-8"?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:basic="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1" xmlns:tns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1"><S:Body><tns:SendRequestRequest><tns:SenderProvidedRequestData Id="SIGNED_BY_CALLER"><tns:MessageID>3784f060-d777-11e8-b0d0-941882013a1a</tns:MessageID><basic:MessagePrimaryContent><req:ImportChargesRequest xmlns:org="http://roskazna.ru/gisgmp/xsd/Organization/2.1.0" xmlns:com="http://roskazna.ru/gisgmp/xsd/Common/2.1.0" xmlns:chg="http://roskazna.ru/gisgmp/xsd/Charge/2.1.0" xmlns:pkg="http://roskazna.ru/gisgmp/xsd/Package/2.1.0" xmlns:req="urn://roskazna.ru/gisgmp/xsd/services/import-charges/2.1.0" xmlns:rfd="http://roskazna.ru/gisgmp/xsd/Refund/2.1.0" xmlns:pmnt="http://roskazna.ru/gisgmp/xsd/Payment/2.1.0" Id="G_fce0c544-b08d-44bc-83d8-738f10e9d069" timestamp="2019-03-12T15:27:53.045+03:00" senderIdentifier="002648" senderRole="1"><pkg:ChargesPackage><pkg:ImportedCharge Id="I_54a59db2-3845-4915-8770-dd95394aadb1" originatorId="002648" supplierBillID="0000980011923591101042012" billDate="2019-03-12T14:06:30.313+03:00" totalAmount="500000" purpose="Oplata" kbk="32111301031016000130" oktmo="45348000"><org:Payee name="FGBU" inn="6639001506" kpp="668301001" ogrn="1026601982220"><com:OrgAccount accountNumber="40101810045250010041"><com:Bank name="GU Bank" bik="044525000" /></com:OrgAccount></org:Payee><chg:Payer payerIdentifier="1220000000007712579832" payerName="Test payer" /><chg:BudgetIndex status="01" paytReason="0" taxPeriod="0" taxDocNumber="0" taxDocDate="0" /></pkg:ImportedCharge></pkg:ChargesPackage></req:ImportChargesRequest></basic:MessagePrimaryContent><tns:TestMessage /></tns:SenderProvidedRequestData><tns:CallerInformationSystemSignature><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411" /><Reference URI="#I_54a59db2-3845-4915-8770-dd95394aadb1"><Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><Transform Algorithm="urn://smev-gov-ru/xmldsig/transform" /></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411" /><DigestValue>M9V0P2X/OzfdAg50nAPmwis2biPC6SYQg5LXzJmqcvA=</DigestValue></Reference><Reference URI="#SIGNED_BY_CALLER"><Transforms><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><Transform Algorithm="urn://smev-gov-ru/xmldsig/transform" /></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411" /><DigestValue>pC1dbY64eP8UP/JJ1U3D9g8vzzg7014b4JsCPyXpIK4=</DigestValue></Reference></SignedInfo><SignatureValue>gcMjIN8F3rEfsE8TKTnk+V7vSwxDNGN6p0g6LKGDObtsyK7h1LWIFsGJNMj4kR72RLsRMrNhRmFT7xxtG556zg==</SignatureValue><KeyInfo><X509Data><X509Certificate>MIIKOjCCCemgAwIBAgIRAK9j4HrEDMmA6BGZiSd8oxEwCAYGKoUDAgIDMIIBcTEeMBwGCSqGSIb3DQEJARYPY2FAc2tia29udHVyLnJ1MRgwFgYFKoUDZAESDTEwMjY2MDU2MDY2MjAxGjAYBggqhQMDgQMBARIMMDA2NjYzMDAzMTI3MQswCQYDVQQGEwJSVTEzMDEGA1UECAwqNjYg0KHQstC10YDQtNC70L7QstGB0LrQsNGPINC+0LHQu9Cw0YHRgtGMMSEwHwYDVQQHDBjQldC60LDRgtC10YDQuNC90LHRg9GA0LMxLDAqBgNVBAkMI9Cf0YAuINCa0L7RgdC80L7QvdCw0LLRgtC+0LIg0LQuIDU2MTAwLgYDVQQLDCfQo9C00L7RgdGC0L7QstC10YDRj9GO0YnQuNC5INGG0LXQvdGC0YAxKTAnBgNVBAoMINCQ0J4gItCf0KQgItCh0JrQkSDQmtC+0L3RgtGD0YAiMSkwJwYDVQQDDCDQkNCeICLQn9CkICLQodCa0JEg0JrQvtC90YLRg9GAIjAeFw0xODA3MTcwODAzMDBaFw0xOTA4MTcwODEyMDBaMIICDjE1MDMGA1UEAx4sBBoEIwQcBBgAIAQQBBQEHAQYBB0EGAQhBCIEIAQQBCYEGAQYACAEEQQTBB4xGTAXBgNVBAQeEAQaBEAEMARBBD0EPgQyBDAxKzApBgNVBCoeIgQVBDIEMwQ1BD0EOARPACAEIQQ1BEAEMwQ1BDUEMgQ9BDAxCzAJBgNVBAYTAlJVMTcwNQYDVQQIHi4ANgA2ACAEIQQyBDUEQAQ0BDsEPgQyBEEEOgQwBE8AIAQ+BDEEOwQwBEEEQgRMMR0wGwYDVQQHHhQEEQQ1BDsEPgRPBEAEQQQ6BDgEOTE1MDMGA1UECR4sBCMEGwQYBCYEEAAgBBsEFQQdBBgEHQQQACwAIAAyADYAMwAsACAAMQAxADExNTAzBgNVBAoeLAQaBCMEHAQYACAEEAQUBBwEGAQdBBgEIQQiBCAEEAQmBBgEGAAgBBEEEwQeMSEwHwYDVQQMHhgEPwRABDUENARBBDUENAQwBEIENQQ7BEwxGDAWBgUqhQNkARINMTAyNjYwMTk4MjIyMDEWMBQGBSqFA2QDEgswNjcyMzY2ODQ4NTEaMBgGCCqFAwOBAwEBEgwwMDY2MzkwMDE1MDYxSTBHBgkqhkiG9w0BCQEWOjcwODFjZmZjY2FhZDZiMzVjMmU4Zjk0NzM3NmU1MTNjQGNhLnNrYmtvbnR1ci5yb3NyZWVzdHIucnUwYzAcBgYqhQMCAhMwEgYHKoUDAgIkAAYHKoUDAgIeAQNDAARAL60/PREHbYeDHVt3UthJ0XaNUepprZCgdG9gC/5oxwp+LB6iQReQ/KbdZwG8grCeuJjzLcYg8/SG2EAzMyG0NaOCBbcwggWzMA4GA1UdDwEB/wQEAwIE8DAlBgNVHREEHjAcgRprdW1pLmltdXNoZXN0dm9AcmFtYmxlci5ydTATBgNVHSAEDDAKMAgGBiqFA2RxATBWBgNVHSUETzBNBggrBgEFBQcDAgYHKoUDAgIiBgYIKwYBBQUHAwQGCCqFAwUBGAITBggqhQMDBQoCDAYHKoUDAwcIAQYHKoUDAwcDFwYIKoUDAwcAAQ0wggGGBgNVHSMEggF9MIIBeYAUgHDPPi7kebNEiHdJDlVHFvDDrdahggFSpIIBTjCCAUoxHjAcBgkqhkiG9w0BCQEWD2RpdEBtaW5zdnlhei5ydTELMAkGA1UEBhMCUlUxHDAaBgNVBAgMEzc3INCzLiDQnNC+0YHQutCy0LAxFTATBgNVBAcMDNCc0L7RgdC60LLQsDE/MD0GA1UECQw2MTI1Mzc1INCzLiDQnNC+0YHQutCy0LAsINGD0LsuINCi0LLQtdGA0YHQutCw0Y8sINC0LiA3MSwwKgYDVQQKDCPQnNC40L3QutC+0LzRgdCy0Y/Qt9GMINCg0L7RgdGB0LjQuDEYMBYGBSqFA2QBEg0xMDQ3NzAyMDI2NzAxMRowGAYIKoUDA4EDAQESDDAwNzcxMDQ3NDM3NTFBMD8GA1UEAww40JPQvtC70L7QstC90L7QuSDRg9C00L7RgdGC0L7QstC10YDRj9GO0YnQuNC5INGG0LXQvdGC0YCCCwDtc8yuAAAAAAF6MB0GA1UdDgQWBBSVGaNnx+bbHq7IgAmo7Dma3oDrmTArBgNVHRAEJDAigA8yMDE4MDcxNzA4MDMwMFqBDzIwMTkwODE3MDgwMzAwWjCCATMGBSqFA2RwBIIBKDCCASQMKyLQmtGA0LjQv9GC0L7Qn9GA0L4gQ1NQIiAo0LLQtdGA0YHQuNGPIDQuMCkMUyLQo9C00L7RgdGC0L7QstC10YDRj9GO0YnQuNC5INGG0LXQvdGC0YAgItCa0YDQuNC/0YLQvtCf0YDQviDQo9CmIiDQstC10YDRgdC40LggMi4wDE/QodC10YDRgtC40YTQuNC60LDRgiDRgdC+0L7RgtCy0LXRgtGB0YLQstC40Y8g4oSWINCh0KQvMTI0LTI4NjQg0L7RgiAyMC4wMy4yMDE2DE/QodC10YDRgtC40YTQuNC60LDRgiDRgdC+0L7RgtCy0LXRgtGB0YLQstC40Y8g4oSWINCh0KQvMTI4LTI5ODMg0L7RgiAxOC4xMS4yMDE2MCMGBSqFA2RvBBoMGCLQmtGA0LjQv9GC0L7Qn9GA0L4gQ1NQIjB0BgNVHR8EbTBrMDOgMaAvhi1odHRwOi8vY2RwLnNrYmtvbnR1ci5ydS9jZHAva29udHVyLXEtMjAxNy5jcmwwNKAyoDCGLmh0dHA6Ly9jZHAyLnNrYmtvbnR1ci5ydS9jZHAva29udHVyLXEtMjAxNy5jcmwwgc4GCCsGAQUFBwEBBIHBMIG+MDMGCCsGAQUFBzABhidodHRwOi8vcGtpLnNrYmtvbnR1ci5ydS9vY3NwcTIvb2NzcC5zcmYwQgYIKwYBBQUHMAKGNmh0dHA6Ly9jZHAuc2tia29udHVyLnJ1L2NlcnRpZmljYXRlcy9rb250dXItcS0yMDE3LmNydDBDBggrBgEFBQcwAoY3aHR0cDovL2NkcDIuc2tia29udHVyLnJ1L2NlcnRpZmljYXRlcy9rb250dXItcS0yMDE3LmNydDCBkwYHKoUDAgIxAgSBhzCBhDB0FkJodHRwOi8vY2Euc2tia29udHVyLnJ1L2Fib3V0L2RvY3VtZW50cy9jcnlwdG9wcm8tbGljZW5zZS1xdWFsaWZpZWQMKtCh0JrQkSDQmtC+0L3RgtGD0YAg0Lgg0KHQtdGA0YLRg9C8LdCf0YDQvgMCBeAEDNuzF16Lytv8Kk79lzAIBgYqhQMCAgMDQQAGLJQXwgAj0LfTBAl0oa0urlNF75tYVFNKcV+WXCG9qIK/MuOBBYZJrN/6VxvEI5cT8gZL2bpnjDTOnSJpa39g</X509Certificate></X509Data></KeyInfo></Signature></tns:CallerInformationSystemSignature></tns:SendRequestRequest></S:Body></S:Envelope>
Offline two_oceans  
#111 Оставлено : 15 марта 2019 г. 9:14:17(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 284
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 17 раз
Поблагодарили: 66 раз в 64 постах
Автор: Соня Базурова Перейти к цитате
Никак не получается сформировать корректный xml-пакет (отправка начисления). При проверке на портале https://smev3.gosuslugi....portal/checkxmlform.jsp, результат:
ЭЦП не подтверждена: #I_54a59db2-3845-4915-8770-dd95394aadb1 Ошибка проверки ЭП: Нарушена целостность ЭП

MS .Net версии 3.5.

Подписываю так:
Код:

      references[0] = "I_54a59db2-3845-4915-8770-dd95394aadb1";
      references[1] = "SIGNED_BY_CALLER";

.Net желательно версии 4.5 или выше для корректного выполнения приведения к каноническому виду, ранние версии не выполняют всех требований стандарта XmlDsigExcC14NTransform, поэтому некоторые файлы могут проходить проверку, а некоторые нет.

Сам подписанный файл пока не смотрел, уже по этим строкам есть что сказать: создали одну подпись и свалили в нее все референсы. Смысл в том, что у Вас референсы пересекаются (1-й содержит 0-й) и при подписи одного может меняться другой из-за указания enveloped трансформа. Поэтому обратите внимание, что они не совместимы в одной подписи с такими трансформами, а каждый референс должен добавляться к отдельной подписи.

Подписание очень чувствительно к порядку операций и к указываемых в reference идентификаторах подписываемых узлов. Правильный порядок следующий:
шаг 1) подписываете начисление, в данном случае идентификатор "I_54a59db2-3845-4915-8770-dd95394aadb1". В СМЭВ 2 это было обязательно, но в СМЭВ 3 я что-то не вижу подписи в схеме данных. В спойлере информация об этой подписи в смэв2.


шаг 2) подписываете тег под MessagePrimaryContent, в данном случае ImportChargesRequest с идентификатором "G_fce0c544-b08d-44bc-83d8-738f10e9d069" Этот тег содержит в себе все начисления, поэтому если сделать шаг 2 ранее чем шаг 1, то при шаге 1 содержимое изменится и подпись не пройдет проверку. Эта подпись помещается в PersonalSignature. Поэтому XmlDsigEnvelopedSignatureTransform не нужен. По схеме эта подпись не обязательная для теста можно пропустить шаг.

шаг 3) Обязательный. Подписываете SenderProvidedRequestData с идентификатором "SIGNED_BY_CALLER" и помещаете подпись в CallerInformationSystemSignature. Тут на первый взгляд все сделано верно, надо только выкинуть референс на начисление "I_54a59db2-3845-4915-8770-dd95394aadb1" и XmlDsigEnvelopedSignatureTransform. Либо можно попробовать референс "I_54a59db2-3845-4915-8770-dd95394aadb1" оставить, но XmlDsigEnvelopedSignatureTransform убрать из обоих референсов.

К слову, если использовать все три трансформа, Enveloped должен добавляться самым первым (уменьшает объем данных, но при уменьшении может испортить каноническую форму и смэвовскую форму), потом C14N (может как уменьшить, так и увеличить объем данных, убирает переводы строк и табуляцию в самом теге, но портит с высокой степенью вероятности смэвовскую форму), потом смэвовский трансформ (переставляет объявление пространства имен тега в начало, исправляет возможную проблему с переводами строк и табуляциями путем их удаления, однако если атрибуты были разделены переводами строк и табуляциями, то без выполнения трансформа C14N перед смевовским получится нечитаемая каша). В порядке
Код:
исходные данные -> Enveloped -> C14N -> смэвовский -> данные для хэша
они друг другу не мешают.

По тексту документа, кажется должно быть chg:Payee, tns:MessagePrimaryContent и обязателен тег
Код:
<chg:ChangeStatus meaning="1"/>
Ещё нюанс - с тегом TestMessage ответ будет от тестового эмулятора, а эмулятор отвечает штатно только на заданный в примере идентификатор платежа или начисления.

Отредактировано пользователем 15 марта 2019 г. 9:34:24(UTC)  | Причина: Не указана

Offline Соня Базурова  
#112 Оставлено : 15 марта 2019 г. 12:38:53(UTC)
Соня Базурова

Статус: Новичок

Группы: Участники
Зарегистрирован: 29.12.2014(UTC)
Сообщений: 2
Российская Федерация
Откуда: Москва

Спасибо Bpar за пример Class1.cs в файле SMEV3sign.zip :) Получился код, подписывающий xml-пакеты, проходящие проверку на портале Смэв3.

При подписании используются ключи ГОСТ-2012 (обычно всегда в примерах ГОСТ-2001).


Пакет импорта начисления:


Спасибо two_oceans за подробный ответ. Рекомендации:
Цитата:

исходные данные -> Enveloped -> C14N -> смэвовский -> данные для хэша
chg:Payee
chg:ChangeStatus meaning="1"/

учтены :)

Цитата:

Ещё нюанс - с тегом TestMessage ответ будет от тестового эмулятора, а эмулятор отвечает штатно только на заданный в примере идентификатор платежа или начисления.


Т.е., тестовый контур (http://smev3-n0.test.gosuslugi.ru:7500/smev/v1.2/ws) отвечает только на пакеты с тегом TestMessage?

Пакет с начислением, отправленный на контур разработки (http://smev3-d.test.gosuslugi.ru:7500/smev/v1.2/ws) возвращает:

<Description>SMEV-401:Не найден вид сведений.</Description>
<ns3:RootElementLocalName>ImportChargesRequest</ns3:RootElementLocalName>
<ns3:RootElementNamespaceURI>urn://roskazna.ru/gisgmp/xsd/services/import-charges/2.1.0</ns3:RootElementNamespaceURI>

Отредактировано пользователем 24 марта 2019 г. 5:44:37(UTC)  | Причина: Не указана

RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
6 Страницы«<456
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.