Signing not working

[profmaad]

Hi there.

I tried doing my "Umsatzsteuer-Voranmeldung" with geierlein for the first time today. I used taxbird until last month, but on my new system, I thought I'd give the future a chance. ^^

After entering all my data, I tried sending a test case. I selected my certificate and entered the pin and got the message, that either the file or the pin are wrong.
I tried sending a non-test transmission, same thing.

I checked the pfx-file using openssl pkcs12. It contains a key named "signaturekey" and the pin is working as well.

So for, I have not been able to either get geierlein to sign the transmission or let me debug the problem.
Any help would be greatly appreciated, I really don't want to start my Wind$$s VM every month just to use elsteronline.de

Thanks in advance. :-)

[stesie]

Hi,

since you've used Taxbird before, do you use an unmodified PFX as provided by Elster Online or do you have a stripped down one? Since Taxbird didn't corretly handle PFX containers with both 1024 and 2048 bit keys it was rather popular to remove the 1024 bit version with Mozilla's certutil... however a stripped PFX already caused problems (issue #14)

On the other hand the emitted error message is a bit unspecific. Could you please modify the file chrome/content/js/geierlein.js around line 127. There's a try-catch-construct wrapping a call to signer.setKeyFromPkcs12Der which causes the error. In the catch clause you find the error message you mentioned. Please just add another alert statement like

alert(e.message);

... then try again and provide the emitted message here.

cheers,
stesie

PS: never mind, I'm quite sure you'll not have to start that very VM :-)

[profmaad]

Here is the message: PKCS#12 PFX has not exactly one bag named signaturekey.

From what I can tell, there is both a "shrouded bag" and a certificate bag named signaturekey in the pfx file.
As far as I can remember, its the pfx I got from elster.

[stesie]

please try editing file chrome/content/lib/geierlein/signer.js at line 68.

There you should see the line

var keyBag = p12.getBagsByFriendlyName('signaturekey');

rewrite it to

var keyBag = p12.getBagsByFriendlyName('signaturekey', forge.pki.oids.pkcs8ShroudedKeyBag);

It's a bit strange that your PFX has two bags with the friendlyName signaturekey. The PFX-files from the fiscal authorities usually have one bag with this friendlyName (the shrouded key bag). This bag has a local-key-id which matches the local-key-id of one certificate in the PFX container.

Therefore another problem might arise, if your PFX file lacks the local-key-id attributes. But let's see :-)

[profmaad]

Now, upon sending a test transmission, I get the following error message:

Die Datenübertragung wurde vom Server abgebrochen:
-1: Signature core validation failed
Fehlercode: 080015006

[stesie]

I'm pretty sure that there's something wrong with the PFX file you have.

Please try logging into the Elster Online portal and change your password there. This should result in a completely regenerated PFX container file.

[stesie]

no reply.

[AlbertoGP]

I've just observed this too. Until now I've always done the UStVA using ELSTER Online, but I'm trying to use the Node.js command line version of geierlein. This time I've done it manually again so there is no time pressure or anything. :-)

The PFX certificate file is exactly the one I got from ELSTER. I haven't touched the file, and it has always worked fine with ELSTER's applet.

I cloned geierlein from github, then installed iconv, optimist, crc32 and deflate-js (the last two needed by gzip-js) using npm, then added your forks of gzip-js and forge:

git clone git://github.com/stesie/gzip-js.git chrome/content/lib/gzip-js/
git clone git://github.com/stesie/forge.git chrome/content/lib/forge/

Then I modified bin/geierlein to load my certificate file instead of the test one, and tried to submit my ustva file with:

bin/geierlein --sign --file ustva_2012-09.geier >ustva_2012-09-protocol.xml

At this point I got the exception from the certificate file not having "exactly one bag named signaturekey", although in quite a strange form:

SoftPSE password: tty.setRawMode: Use `process.stdin.setRawMode()` instead.


/stor/src/geierlein/chrome/content/lib/geierlein/signer.js:71
                message: 'PKCS#12 PFX has not exactly one ' +
                                                            ^
[object Object]

It seems that the exception is handled by node.js in some wrong way, but I think this in unrelated to the issue at hand.

Alright, then I made the modification you described above:

var keyBag = p12.getBagsByFriendlyName('signaturekey', forge.pki.oids.pkcs8ShroudedKeyBag);

After this, there were no exceptions:

SoftPSE password: tty.setRawMode: Use `process.stdin.setRawMode()` instead.

However, there is that error message in the protocol file:

<Rueckgabe><Code>080015006</Code><Text>-1: Signature core validation failed</Text></Rueckgabe>

One thing I notice in the protocol XML file is that the TransportSchluessel field has a new-line character in it; should its content be all in one line?
Another thing is that the file I submit, ustva_2012-09.geier, has umlaute and accents encoded as UTF-8. Is this alright, or should it be Latin-1?

[stesie]

The document that is sent to the fiscal authorities must be ISO-8859-1 (or 15). However Geierlein internally uses UTF-8, especially regarding the result XML.

Exception reporting is a bit strange since Node.js expects a string (i.e. error message) to be thrown. However the Forge library throws objects, that contain the error message (and possibly further information). Hence the [object Object] output ;-)

Could you please provide the output of openssl pkcs12 -in your.pfx -nodes. But please make sure to replace the Base64-encoded data, especially of the private keys, ... by dummy values (or just strip them). I'm interested in which bags are wrapped in the PFX.

cheers
stesie

[AlbertoGP]

openssl pkcs12 -in signature_file_from_elster_2048.pfx -nodes

MAC verified OK
Bag Attributes
    friendlyName: encryptionkey
    localKeyID: <18 pairs of hex digits>
Key Attributes: <No Attributes>
-----BEGIN PRIVATE KEY-----
<blah-blah-blah>
-----END PRIVATE KEY-----
Bag Attributes
    friendlyName: signaturekey
    localKeyID: <18 pairs of hex digits>
Key Attributes: <No Attributes>
-----BEGIN PRIVATE KEY-----
<blah-blah-blah>
-----END PRIVATE KEY-----
Bag Attributes
    friendlyName: encryptionkey
    localKeyID: <18 pairs of hex digits>
subject=/serialNumber=1002957885C/CN=1002957885
issuer=/C=DE/O=Elster/OU=CA/CN=ElsterSoftCA
-----BEGIN CERTIFICATE-----
<blah-blah-blah>
-----END CERTIFICATE-----
Bag Attributes
    friendlyName: CN=ElsterSoftCA,OU=CA,O=Elster,C=DE
subject=/C=DE/O=Elster/OU=CA/CN=ElsterSoftCA
issuer=/C=DE/O=Elster/OU=RootCA/CN=ElsterRootCA
-----BEGIN CERTIFICATE-----
<blah-blah-blah>
-----END CERTIFICATE-----
Bag Attributes
    friendlyName: CN=ElsterRootCA,OU=RootCA,O=Elster,C=DE
subject=/C=DE/O=Elster/OU=RootCA/CN=ElsterRootCA
issuer=/C=DE/O=Elster/OU=RootCA/CN=ElsterRootCA
-----BEGIN CERTIFICATE-----
<blah-blah-blah>
-----END CERTIFICATE-----
Bag Attributes
    friendlyName: signaturekey
    localKeyID: <18 pairs of hex digits>
subject=/serialNumber=1002957885A/CN=1002957885
issuer=/C=DE/O=Elster/OU=CA/CN=ElsterSoftCA
-----BEGIN CERTIFICATE-----
<blah-blah-blah>
-----END CERTIFICATE-----
Bag Attributes
    friendlyName: CN=ElsterSoftCA,OU=CA,O=Elster,C=DE
subject=/C=DE/O=Elster/OU=CA/CN=ElsterSoftCA
issuer=/C=DE/O=Elster/OU=RootCA/CN=ElsterRootCA
-----BEGIN CERTIFICATE-----
<blah-blah-blah>
-----END CERTIFICATE-----
Bag Attributes
    friendlyName: CN=ElsterRootCA,OU=RootCA,O=Elster,C=DE
subject=/C=DE/O=Elster/OU=RootCA/CN=ElsterRootCA
issuer=/C=DE/O=Elster/OU=RootCA/CN=ElsterRootCA
-----BEGIN CERTIFICATE-----
<blah-blah-blah>
-----END CERTIFICATE-----

[trs123]

I'm having the same problem.

My pfx file (which I downloaded today) looks similar (two entries each for signaturekey and encryptionkey).

[stesie]

well, that looks really weird. I've got no recently created official PFX, just those test certificates provided with the specs. I'll do the registration process and hope that I'll get such a certificate as well.

Have you tried sending the data without signature as a testcase? Does that work or does the data itself maybe cause problems?

[AlbertoGP]

I've just tried the following: bin/geierlein --testcase --file ustva_2012-09.geier
There are no error messages, and I get a protocol XML document. I copy here a redacted version, with some indentation added for clarity:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="/stor/src/geierlein/bin/../chrome/content/xsl/ustva.xsl"?>
<Elster xmlns="http://www.elster.de/2002/XMLSchema">
  <TransferHeader version="8">
    <Verfahren>ElsterAnmeldung</Verfahren>
    <DatenArt>UStVA</DatenArt>
    <Vorgang>send-NoSig</Vorgang>
    <TransferTicket>2453536603070750352</TransferTicket>
    <Testmerker>700000004</Testmerker>
    <HerstellerID>74931</HerstellerID>
    <DatenLieferant>*** my corect data: name, address, etc ***</DatenLieferant>
    <EingangsDatum>20121011002246</EingangsDatum>
    <Datei>
      <Verschluesselung>PKCS#7v1.5</Verschluesselung>
      <Kompression>GZIP</Kompression>
      <DatenGroesse>1300</DatenGroesse>
      <TransportSchluessel>*** Base64 or similar encoding ***</TransportSchluessel>
    </Datei>
    <RC><Rueckgabe><Code>0</Code><Text>Daten wurden erfolgreich angenommen.</Text></Rueckgabe><Stack><Code></Code><Text></Text></Stack></RC>
    <VersionClient>0.3.4</VersionClient>
    <Zusatz><ElsterInfo>Aufgrund einer Gesetzesänderung ist die von Ihnen gewählte Übermittlungsart ab dem 01.01.2013 nicht mehr möglich. Für die dann erforderliche authentifizierte Übermittlung ist eine rechtzeitige Registrierung unter www.elsteronline.de durchzuführen.</ElsterInfo></Zusatz>
  </TransferHeader>
  <DatenTeil><Nutzdatenblock><NutzdatenHeader version="10"><NutzdatenTicket>*** 7 digits ***</NutzdatenTicket><Empfaenger id="F">1040</Empfaenger><Hersteller><ProduktName>Geierlein</ProduktName><ProduktVersion>0.3.4</ProduktVersion></Hersteller><DatenLieferant>*** again my data, correct ***</DatenLieferant><RC><SigIntern></SigIntern><VerarbeitungsVersion></VerarbeitungsVersion><Rueckgabe><Code>0</Code><Text></Text></Rueckgabe><Stack><Code></Code><Text></Text></Stack></RC></NutzdatenHeader><Nutzdaten>
    <Anmeldungssteuern art="UStVA" version="201201">
        <DatenLieferant><Name>*** name ***</Name><Strasse>*** street and number ***</Strasse><PLZ>*** postal code ***</PLZ><Ort>*** city ***</Ort><Telefon>*** phone number ***</Telefon><Email>*** e-mail ***</Email></DatenLieferant>
        <Erstellungsdatum>20121011</Erstellungsdatum>
        <Steuerfall>
            <Umsatzsteuervoranmeldung>
                <Jahr>2012</Jahr>
                <Zeitraum>09</Zeitraum>
                <Steuernummer>*** tax number ***</Steuernummer>
                <Kz09>*** some integer number, I don't know right now what it is ***</Kz09>
                <Kz66>*** correct amount, dot with two decimals ***</Kz66>
                <Kz81>*** correct amount, integer ***</Kz81>
                <Kz83>*** correct amount, dot with two decimals</Kz83>
            </Umsatzsteuervoranmeldung>
        </Steuerfall>
    </Anmeldungssteuern>
</Nutzdaten></Nutzdatenblock></DatenTeil></Elster>

Now, as long as I use the --testcase option, the Finanzamt doesn't store any of this data, right?
Does it matter which certificate I use with the testcase option, or should I use the test certificate file at tests/_files/test-softpse_rsapss.pfx?
I'm sorry for these basic questions, but it's not clear to me how that option works.
Anyway, I guess that the answer to the first one is "no" so I've tried the following just for completeness: bin/geierlein --testcase --sign --file ustva_2012-09.geier, and I get the same error again in the XML protocol output: <Rueckgabe><Code>080015006</Code><Text>-1: Signature core validation failed</Text></Rueckgabe>

What if I do a normal transmission (no testcase) without the --sign option? I did that the first time by mistake, and although I've lost that protocol file I remember that it included that message about the current method no longer being valid from 01.01.2013. I'm not sure whether it had some error message besides that. There were no error messages in the console.
I didn't get any kind of acknowledgement of that submission, though. I guess I would get some e-mail just like when I submit through ELSTER Online. Do people that use Taxbird or Geierlein get a confirmation e-mail?

[stesie]

oh dear, the test certificate is hard coded in the Node.js version (bin/geierlein file). Completely forgot about that one :(
anyways, I think you've found that out already.

The authentication process itself is completely decoupled from the tax case itself (as far as I know). That is you should be able to send tax cases for any tax number (e.g. one of a friend) with your certificate. It just makes clear who has sent the tax form, not whether she's permitted to do so.

Put short you can use your personal certificate for testcases. The test pfx you've found (pincode 123456 by the way) can be used for testcases but need not be. However it must not be used for real world cases for obvious reasons.

Signatures are not yet mandatory (before 01.01.2013), hence you can just leave it away (this year). However fiscal authorities might prompt you whether the data was submitted by you (in case you've once sent a tax case with signature).

Concerning the "Signature core validation failed" error, you did change bin/geierlein to point to your PFX before, didn't you? I would have supposed this to happen, since the JavaScript code behind the scenes is almost the same.

Could you please try out sending the exact same ustva_2012-09.geier with the test-softpse_rsapss.pfx as a testcase? If that works, we can assume that there's still a problem with newer PFX files. If not it's due to the data being sent.

PS: fiscal authorities don't generate confirmation mails for tax cases submitted with Taxbird/Geierlein, just for Elster Online. The transmission you did (probably) was successful (since you've seen the XHTML document). On error no XHTML is written out.

[stesie]

argh, am I correct that both your names/addresses contain umlauts? If so, could you please test whether everything works correctly if you replace the umlauts?

I've never tested with those but can reproduce that it fails if I arbitrarily add ones.

[AlbertoGP]

It's the umlauts. Sending as test case works with both my certificate and the test one if I remove any non-ASCII characters, and it fails in both cases as soon as there is one such character anywhere ("name", "strasse", or "ort").
Keep in mind that this still requires the modification to chrome/content/lib/geierlein/signer.js.

My input file is encoded in UTF-8, and has the format of the example doc/examples/ustva.

[stesie]

Ok, thanks for testing this. And yes I'm well aware that I need to modify signer.js

The problem with the signature is that it's calculated over the UTF-8 encoded string. The Elster clearing server checks the signature against the Latin-1 encoding.

The input file to Geierlein must be encoded in UTF-8

[stesie]

Hi,

could you please give the Git-version auf Geierlein a try? The GUI version should work now, haven't yet cared for the command line version.

cheers,
stesie

[AlbertoGP]

I've tried with the command line version as the files you modified are common to both, and sending my data with my signature as test case with bin/geierlein --testcase --sign signature_file_from_elster_2048.pfx --file ustva_2012-09.geier works perfectly now.

Thanks!

[trs123]

I've tried with the GUI version and sending my data as a test case with signature works fine now!

Thanks!

P.S. curiously neither my name nor my address contains umlauts or other non-ASCII characters...

[AlbertoGP]

There were two independent problems:

• geierlein did not find the signing key in the PFX file. This is the first issue we all encountered.
• after that was fixed, the signing procedure did not work right if you had non-ASCII characters in your data, as was my case.

Now both things are solved.

[trs123]

Ah, of course! Thanks.