A new advisory from the Office of the Controller of Certifying Authorities requires SHA-2 across applications, APIs, middleware and backend services, and bars SHA-1 and MD5 from generating new signatures, hashes or timestamps.
The advisory is two pages and says one thing plainly. If your application, API, middleware or backend signs anything with a DSC, it must use SHA-2 based algorithms, and it must stop using SHA-1 and MD5 to generate new signatures, document hashes or timestamps. The audience is named explicitly: software
developers, application service providers, web portal owners, system integrators, government departments and the Certifying Authorities themselves.
What makes this more than a style note is the second half of the title. FIPS 140-3 compliant tokens and HSMs are entering the ecosystem on the timeline set by the CCA's separate migration advisory. A module running in approved mode will not hand you a SHA-1 signature. So a stack that still asks for one does not degrade gracefully - it stops signing.
ONE REQUEST, TWO ALGORITHMS
The algorithm is chosen in your code, but it is enforced four hops away. That gap is the whole problem: the hash name travels down the stack as a parameter, and nothing between your call and the device has any reason to object to SHA1withRSA - until the device does.
The same request, descending the same stack twice. Each arrow carries the algorithm choice made at stage 1 one hop further down; stages 2 and 3 pass it along without judging it. The two paths are identical until the device, which is the only component that refuses.
Stage 1 Application SHA-256 vs SHA-1 / MD5
Stage 2 Signing layer SHA256withRSA vs SHA1withRSA
Stage 3 Middleware CKM_SHA256_RSA_PKCS vs CKM_SHA1_RSA_PKCS
Stage 4 Device approved mechanism vs no approved path
Stage 5 Outcome signature issued vs signing fails
Mechanism names in the diagram are PKCS#11. The same decision lives in a CSP/KSP algorithm identifier on Windows, or a JCA signature name on the JVM - different spelling, same parameter travelling down the same chain.
WHAT IS ACTUALLY MANDATED
1. SHA256withRSA, or ECDSA with SHA-256.
The signature algorithms required for DSC-based operations.
Source: CCA Interoperability Guidelines
2. SHA-256 document hash, and SHA-256 signature hash.
Two separate settings in the eSign API specifications. Teams often fix one and miss the other.
Source: eSign API specifications
3. No SHA-1, no MD5.
For generation of new digital signatures, document hashes or timestamps, in applications, APIs, middleware, signing components and backend services.
Source: the advisory note
4. SHA-2 and FIPS 140-3 compatibility.
Cryptographic libraries, middleware, PKCS#11 modules and CSP/KSP implementations must work against FIPS 140-3 tokens and HSMs.
Note the second item in particular. The eSign API specifications set the document hash and the signature hash algorithm as two separate values, and a team that fixes one frequently leaves the other alone.
WHERE SHA-1 STILL HIDES
The advisory asks stakeholders to review and update applications, cryptographic libraries, middleware, PKCS#11 modules and CSP/KSP implementations, and related interfaces. In practice the dependency is rarely in the line of code anyone remembers writing.
Library defaults.
An older signing SDK, or a wrapper around it, may still default to SHA1withRSA when no algorithm is passed. Nothing at the call site shows it.
Config strings.
Signature algorithm, digest algorithm and timestamp digest are frequently three separate keys, set at three different times by three different people.
Token drivers and PKCS#11 modules.
A module that only ever exposed SHA-1 mechanisms will not grow SHA-2 ones. This is the layer most likely to need a vendor upgrade rather than a code change.
Timestamp requests.
Timestamps carry their own message imprint algorithm. A SHA-2 signature with a SHA-1 timestamp request is still a SHA-1 dependency.
Verification code.
Code that validates a signature by comparing against an expected SHA-1 digest length, or that hard-codes an OID, breaks on correct SHA-2 input.
Backend services.
Document pipelines, PDF processors and queue workers that compute the hash before the signing call ever happens.
WHO IS ON THE HOOK
Developers and ASPs
Make applications, APIs, middleware, signing components and backend services use SHA-2 based algorithms; remove SHA-1 and MD5 from generation paths.
Portal owners and system integrators
Review and update cryptographic libraries, PKCS#11 modules, CSP/KSP implementations and related interfaces for SHA-2 and FIPS 140-3 compatibility.
Certifying Authorities
The same obligation, for every component in DSC-based operations, per the Interoperability Guidelines and the eSign API specifications.
Government departments
Complete software modifications and testing well in advance of the FIPS 140-3 migration timelines.
Audit agencies
Verify compliance, and report any use of or dependency on deprecated hash algorithms - to the auditee and to the CCA.
FINDINGS ARE REPORTABLE, IMMEDIATELY
Any use of, or dependency on, SHA-1, MD5 or other deprecated hash algorithms for generating new digital signatures, hashes or timestamps is to be reported to the auditee for corrective action, and to the Office of the CCA at info@cca.gov.in without delay.
TIMELINES COME FROM THE MIGRATION ADVISORY
This note does not set its own dates. It points at the CCA's Advisory Note on FIPS 140-2 to FIPS 140-3 Migration and asks that software modifications and testing be finished well in advance of the timelines stipulated there. Read the two together: that advisory tells you when FIPS 140-3 devices arrive, and this
one tells you what your stack must already be doing by then.
https://cca.gov.in/sites/files/pdf/news/Advisory_on_Migration_from_FIPS_140-2_to_FIPS_140-3.pdf
A SHORT WORKLIST
1. Grep the codebase for SHA1, SHA-1, MD5 and the OIDs 1.3.14.3.2.26 and 1.2.840.113549.2.5 - config files and properties included.
2. Confirm the eSign document hash and the signature hash algorithm are both set to SHA-256.
3. Ask each token and HSM vendor, in writing, for their FIPS 140-3 status and the SHA-2 mechanisms their PKCS#11 module exposes.
4. Check the timestamp request's message imprint algorithm separately from the signature.
5. Test against a FIPS 140-3 device, not only against a software keystore - approved mode is where the refusal shows up.
6. Keep SHA-1 verification of historical signatures if you need it; the prohibition is on generating new ones.
The advisory closes by framing all of this as public interest work: strengthening India's PKI and the trustworthiness of digital transactions. The practical reading is narrower and more urgent. SHA-1 in a signing stack used to be a finding in an audit report. Once the device underneath it is FIPS 140-3,
it becomes an outage.
SOURCE
Advisory Note - "Ensuring Compatibility with SHA-2 and FIPS 140-3 Compliant Cryptographic Devices", Office of the Controller of Certifying Authorities, Ministry of Electronics and Information Technology, Government of India.
The mandates, the list of responsible parties and the reporting requirement above are drawn from that note. The worklist, the hiding places and the diagram's mechanism names are practitioner commentary, not part of the advisory text.