Próbował już ktoś tworzyć aplikacje do wysyłania JPK zgodnie ze specyfikacją MF? Przebrnąć przez te wszystkie kompresje, kodowanie, generowanie xml, podpis elektroniczny i podłączenie się do bramki?
Cześć, zacznę od tego, że na przykładach ze stronki mf.gov.pl i własnych udało się zrobić aplikację .Net, która wykonuje wszystkie wymagane operacje na plikach, aż do otrzymania InitUpload.xml, który potem podpisujemy zewnętrznymi aplikacjami Szafir/proCertum i wrzucamy na Azure - w tym momencie trzy kroki wykonywane przez dwie różne apki.
Krok1: (C#): Przygotowanie plików i metadanych Krok2: proCertum albo żenujący javovy applet Szafira: Podpisanie pliku Krok3: (C#): Komunikacja z Azurem
@yarpi87 jesteś w stanie przesłać / udostępnić podpisany przykładowy plik .xades przez twoją bibliotekę xadesNet? Może Twój projekt sln XadesNet albo przekompilowaną dllkę? Chciałbym zobaczyć jak biblioteką w wersji .net 3.5 zmieniasz ciąg hexametryczny czterdziestu znaków na integera.
@yarpi87: Haha tak. Widzisz. Regularna wartość tutaj to 40 znakowy ciąg heksametryczny, który wrzucasz do Xadesa pod \X509SerialNumber. XSD XADESA-BES wymaga tam integera, a biblioteka XadesNet nie konwertuje tego ciągu (można to zrobić łatwo w .Net 4.0). U Ciebie wchodzi 01 co pewnie jest pobierane jako int i dlatego masz cacy, a ludzie którzy używają dobrych certyfikatów są w dupie i powinni zedytować bibliotekę:
var serial = BigInteger.Parse(serialHexString, NumberStyles.HexNumber);
@durek89: Czyli w initUpload. masz ....plik1.xml.......plik2.xml.... i jak to podpisujesz to nie wali błędem przy wysyłaniu do MF, że niezgodne ze schemą xsd?
@yarpi87: Przykro mi Panie kolego, ale ten plik jest daleki od poprawnego. masz źle zbudowane, obie sumy kontrolne Digest są niepoprawne, a co za tym idzie i sygnatura. W kanonikalizacji nie podmieniłeś vbCrLf'ów. Kryptograficznie dwója na szynach. : )
@yarpi87: coś mnie zje zaraz od środka. Jak podpisuję programami KIR, proCertum, Signillum, to śmiga i przechodzi bez problemu... jak podpisujemy xadesNetem, microsoft.xadesem, IL.Xadesem albo kodem kolegi @Liferov to zawsze dostajemy "certyfikat negatywnie zweryfikowany" (szczegółowe informacje na walidatorach: NIEPRAWIDŁOWA WARTOŚĆ DIGEST LUDZIE KUR** zapłacę w wódce i miodzie. Pomóżcie! : I
To nie to, biorę przykładowy wygenerowany plik InitUpload.xml zwalidowany względem .xsd - tworzę z niego sześć podpisanych plików, trzy robię appletami licencjonowanymi, kolejne trzy robię Twoją metodą i innymi openSourcowymi. Wszystko wysyłam tą samą metodą na https://test-e-dokumenty.mf.gov.pl/api/Storage/InitUploadSigned. Pierwsze trzy przechodzą całą ścieżkę, reszta cały czas negatywnie zwalidowana.
@mmm234: na Prodzie: {"Code":120,"Description":"Sesja została poprawnie zakończona. Dane zostały poprawnie zapisane. Trwa weryfikacja dokumentu","Details":"","Timestamp":"2016-08-05T15:12:15.4160242+00:00","Upo":""}
@rollon: Wysłałem na PROD pliczek o 12:39 i o 12:45 mam już piękny błąd: "Code":410,"Description":"Przesłane pliki nie są prawidłowym archiwum ZIP.","Details":"ERROR_DECOMPRESS" (używam klucza z pliku 3af5843ae11db6d94edf0ea502b5cd1a.pem) i metody do zipowania: using (var fileStreamIn = new FileStream(inputFile, FileMode.Open, FileAccess.Read)) { using (var fileStreamOut = new FileStream(outputFile, FileMode.Create, FileAccess.Write)) { using (var zipOutStream =
@Gibonowski: rozwiniesz proszę co źle szyfrowałeś? Użyłeś złej metody, złych parametrów? Tu nie ma chyba dużej filozofii RSA: myCertificate to plik .pem | keyForEncryption to wygenerowany klucz using (RSACryptoServiceProvider rsaObj = myCertificate.PublicKey.Key as RSACryptoServiceProvider) { byte[]
@yarpi87: Wysłałem służbowego maila na jpk serwis z prośbą o wyjaśnienie, dlaczego pliki podpisane przez nas oficjalnymi narzędziami nie wchodzą na bramkę MF. Dostaliśmy zwrotkę od billennium, że oni to wrzucają do proCertum i nie waliduje się jakaś część. Na co ja dałem im do zrozumienia, że my każdy podpisany plik przed wysłaniem i tak weryfikujemy w trzech różnych narzędziach i jednym z nich jest właśnie proCertum ( dodałem screena
#programowanie #sap #erp #jpk
zacznę od tego, że na przykładach ze stronki mf.gov.pl i własnych udało się zrobić aplikację .Net, która wykonuje wszystkie wymagane operacje na plikach, aż do otrzymania InitUpload.xml, który potem podpisujemy zewnętrznymi aplikacjami Szafir/proCertum i wrzucamy na Azure - w tym momencie trzy kroki wykonywane przez dwie różne apki.
Krok1: (C#): Przygotowanie plików i metadanych
Krok2: proCertum albo żenujący javovy applet Szafira: Podpisanie pliku
Krok3: (C#): Komunikacja z Azurem
var serial = BigInteger.Parse(serialHexString, NumberStyles.HexNumber);
Niestety
//if (this.signaturePolicyIdentifier != null &&
using (var fileStreamIn = new FileStream(inputFile, FileMode.Open, FileAccess.Read))
{
using (var fileStreamOut = new FileStream(outputFile, FileMode.Create, FileAccess.Write))
{
using (var zipOutStream =
Tu nie ma chyba dużej filozofii RSA:
myCertificate to plik .pem | keyForEncryption to wygenerowany klucz
using (RSACryptoServiceProvider rsaObj = myCertificate.PublicKey.Key as RSACryptoServiceProvider)
{
byte[]