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?
@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 ),
@Gibonowski: @hipek1001: Ok, dzięki. Wrzuciłem już poprawkę do procesu i efekt poszedł na Proda. Zobaczymy jaki będzie efekt. Dzięki za szybką odpowiedź. Jeśli Warszawa, to stawiam piwo.
@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[] cryptedData = rsaObj.Encrypt(keyForEnryption,true); return Convert.ToBase64String(cryptedData); }
@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 = new ZipOutputStream(fileStreamOut)) { zipOutStream.CompressionMethod = CompressionMethod.Deflate; zipOutStream.EnableZip64 = Zip64Option.AsNecessary; zipOutStream.PutNextEntry(Path.GetFileName(inputFile)); fileStreamIn.CopyTo(zipOutStream); } } }
@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":""}
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.
@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
@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. : )
@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: 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);
@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.
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
#programowanie #sap #erp #jpk
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[] cryptedData = rsaObj.Encrypt(keyForEnryption,true);
return Convert.ToBase64String(cryptedData);
}
I w aes:
... encrypt.KeySize = AESKEYSIZE; // 32 BYTES
encrypt.BlockSize = AESBLOCKSIZE; // 16 BYTES
encrypt.Padding = AESPADDING; //PKCS7
encrypt.Mode
using (var fileStreamIn = new FileStream(inputFile, FileMode.Open, FileAccess.Read))
{
using (var fileStreamOut = new FileStream(outputFile, FileMode.Create, FileAccess.Write))
{
using (var zipOutStream = new ZipOutputStream(fileStreamOut))
{
zipOutStream.CompressionMethod = CompressionMethod.Deflate;
zipOutStream.EnableZip64 = Zip64Option.AsNecessary;
zipOutStream.PutNextEntry(Path.GetFileName(inputFile));
fileStreamIn.CopyTo(zipOutStream);
}
}
}
Czy komuś w C# przeszło
//if (this.signaturePolicyIdentifier != null && this.signaturePolicyIdentifier.HasChanged())
//{
// retVal.AppendChild(creationXmlDocument.ImportNode(this.signaturePolicyIdentifier.GetXml(), true));
//}
//else
//{
// throw new CryptographicException("SignaturePolicyIdentifier element missing in SignedSignatureProperties");
//}
i przy wysyłaniu do MF nadal błąd: Podpis jest w innym formacie niż XAdES-BES.
var serial = BigInteger.Parse(serialHexString, NumberStyles.HexNumber);
Niestety to
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
(jeśli ktoś potrzebuje